Жизнь без тестировщиков вполне возможна. Но имеет смысл она в маленьких командах, в которых разработчики не являются инженерами, а, скорее, универсальными специалистами. И эти универсальные специалисты точно так же вполне способны ставить себе задачи, локлизовывать текст (например, написав сервер, сканирующий опенсорс локализацию и по нему вставляя свои строки)
В случае большой задачи одновременное выполнение разработки/тестирования (и любой другой активности не относящейся напрямую к разрабтке) не так эффективно, так как разработчик точно так же как и тестировщик должен потратить на эту активность своё время. Переключение контекста в данном случае приводит к снижению качества и скорости разработки. Иллюстрацией тут может служить конвейерная разработка.
Программист обязан проверить корректное выполнение поставленной задачи. И даже (в случае отсутствия соответствующих ресурсов) написать автоматические тесты. Однако проверку регрессий, производительности, покрытия требований к программному продукту и ручное интеграционное тестирование стоит доверить инженеру контроля качества.
Ну, вообще говоря, когда вы вставляете изображение в новый документ должно быть очевидно что вставка нужна именно в новый документ. Это происходит не автоматически, а по вызову команды из меню или назначенного хоткея.
Неочевидно бывает когда вам нужно вставить изображение в уже открытый документ (когда много открыто) но, насколько я понимаю эта проблема общая для всех графических редакторов. И не только графических редакторов.
Я имею в виду создание нового изображения для редактирования из картинки находящейся в буфере обмена.
Для осуществления данной операции картика или часть картинки из другого документа копируется в буфер после чего создаётся новый документ размер которого в фотошопе автоматически равен размеру картинки в буфере. При вставке новая картинка попадает на новый слой созданного изображения. Drag&Drop тут, в принципе, ни при чём.
Подобные действия сначала вызывали много вопросов у моих знакомых, которых я знакомил с фотошопом (путаница со слоями, неочевидность действий), а потом отсутствие этого алгоритма вызывало вопросы у моих знакомых, которых я знакомил с гимпом (и которые до этого были знакомы с фотошопом)
Ну, здорово. В последнем фотошопе который я использовал этого меню не было (а возможно оно есть только в элементс так как совершенно уверен что разработка ведётся разными командами).
Правда, это никак не опровергает мой тезис о том, что к фотошопу все просто привыкли: запомнили горячие клавиши, привыкли к иконкам и меню. И называют привычку удобством. Так-то оно так, вам (это я обобщённо) лично удобнее. Но про продуманный дизайн я бы утверждать не стал.
Готов обсудить это на отдельных примерах, но, боюсь, я не настолько сильно увлечён этой темой чтобы самостоятельно придумать ещё один.
Не знаю кто продумывал интерфейс фотошопа, но в Гиме и CorelDraw была функция вставить как новую картинку. Гораздо более логичная, вообще говоря, функция (я хотел написать об этом в предыдущем комментарии, но, видимо, не дописал)
И не нужно создавать новую и вставлять как новый слой.
Дизайн интерфейса тут ни при чём. Привычка пользователей, не более.
Не совсем так. Простые юзеры просто привыкли к интерфейсу фотошопа (который, если над этим задуматься, весьма неоднозначный). И теперь не могут понять, например, почему в гимпе у вновь создаваемой картинки размер отличен от той, что скопирвана в буфер обмена.
Обработка исключений не может быть универсальной по своей сути.
Это может быть логгирование (тут, наверное, единственное место универсальное) может быть повтор метода (без вариантов переноса кода), может быть какая-то логика (и тут круто увеличится зависимость одного класса от другого), может быть сложная логика с делегированием части обработки другому классу (программист который передаст, например, ну не знаю, репозиторий базы конструктор исключения должен быть жестоко наказан).
Из-за неуниверсальности обработки код получится сложнее: тут исключение само себя обрабатывает (чтобы узнать как читайти внутри), тут нет. Представьте себя читающим свой же код через 3 года. Хренпоймёшь и без этого, сложности и без этого достаточно. А тут ещё эта дополнительная сложность на пустом месте.
Как-то слабо для Гугла.
Насколько я понимаю самым сложным модулем тут было распознавание текста (и то использовались встроенные библиотеки)
В остальном решение судоку выглядит задачей для второкурсника. Как-то не смотрится тут подпись google engineer. Google intern хотя бы.
Классный Вы парень. Надеюсь, Вы в курсе, что P2P юзается не только для того, чтоб личить с торрентов. Давайте еще запретим хттп, потому что кто-то серфит прон.
Выводы делаем сами — легального механизма для прикрытия торрента в оффшоре — нету. А самый-то сок в том, что он и не нужен. Производители вареза добирают свои деньги на корпоративных изданиях и на юзерах, которым не хочется/не можется возиться с поиском и выкачиванием нужного софта (знаю и таких). Производители гамезов добирают за счет большинства юзеров, которые, заценив достойный продукт, пойдут и приобретут его «для коллекции» или для возможности играть онлайн (например, на батлнете) (ессно, всякую бурду типа «Москва и мертвецы» никто покупать не пойдет, и правильно сделают). Музыканты вообще организовали «Круги», где выкладывают свои альбомы бесплатно, оставляя юзерам возможность напрямую (без посредничества копирастов) скинуть столько денег, сколько считают нужным (и, как показала практика, такая система ох как работает). Производители киноконтента основной доход имеют с проката, а предполагать, что народ перестанет ходить с друзьями и девушками в кино, потому что ту же фильму можно сличить — глупо, на все кассовые картины народ ходит в кинотеатр, а 20% того что личат — в русском прокате нету. Собсно, напрашивается вывод о том, что единственные, кого реально батхёртят файлообменники — это лютые копирасты типа РАО. Которые, заметьте, Шерлоков Холмсов тоже особо не снимают, да?
Ваша аналогия не совсем точная. Правильнее бы так: вы пришли смотреть квартиру. Везде походили, все вроде нормально, все чисто. Потом вдруг говорите: «О, как офигенски здесь бы смотрелась арочка, а вот тут я бы все же стенку наверно подвинул на пару метров, кухня вышла маловатая». И вот тут ребята Вам сразу и скажут «доплати и сделаем, чо» и будут правы. Но шарж-то был о том, что в этой же ситуации рабочие должны были бы сказать «Ты чо, совсем плохой? Какая арка? А кухня у тебя то что надо, тебе ж не еду в ресторане готовить», что звучит как полный абсурд.
На счет того, справедливо ли сравнение разных профессий, спорить можно долго, однако в данном случае можно сказать, что шарж фигня. Ту же сиделку по сто раз в день могут дергать по поводу того, где с дитем гулять, что ему читать и во что с ним играть. Механику запросто могут сказать «а врежь-ка мне на мою копейку плахи на фары, чтоб как у БМВ, и вот это антикрыло еще круто бы приварить». И так далее, в любой профессии можно нати такую ситуацию. Так что: а) неясно, чего это дезигнеры вдруг решили, что их «проблема» специфична именно для их профессии, б) неясно, есть ли вообще такая проблема. То, что взгляды дезигнера и заказчика могут не совпадать — очевидно. Как эти разногласия решать — очевидно: составлением договора. Если фрилансите и договора не хотите — отказывайтесь или играйте по правилам заказчика. А так, если каждый начнет ныть, когда его заставляют делать его же работу…
Насколько я помню в Civilization: Revolution и религия и шпионаж были. Это в новой версии на PC хотят отказаться. И то вроде.
Вы либо неправильно перевели либо неправильно скопипастили.
Уверен, говорят чистейшую правду.
Например, вот такой
www.linkedin.com/search/fpsearch?title=qa+engineer&company=google¤tCompany=C&pplSearchOrigin=TSEO_SN&trk=TSEO_SN&csrfToken=guest_token&domainCountryName=
В случае большой задачи одновременное выполнение разработки/тестирования (и любой другой активности не относящейся напрямую к разрабтке) не так эффективно, так как разработчик точно так же как и тестировщик должен потратить на эту активность своё время. Переключение контекста в данном случае приводит к снижению качества и скорости разработки. Иллюстрацией тут может служить конвейерная разработка.
Программист обязан проверить корректное выполнение поставленной задачи. И даже (в случае отсутствия соответствующих ресурсов) написать автоматические тесты. Однако проверку регрессий, производительности, покрытия требований к программному продукту и ручное интеграционное тестирование стоит доверить инженеру контроля качества.
Неочевидно бывает когда вам нужно вставить изображение в уже открытый документ (когда много открыто) но, насколько я понимаю эта проблема общая для всех графических редакторов. И не только графических редакторов.
Для осуществления данной операции картика или часть картинки из другого документа копируется в буфер после чего создаётся новый документ размер которого в фотошопе автоматически равен размеру картинки в буфере. При вставке новая картинка попадает на новый слой созданного изображения. Drag&Drop тут, в принципе, ни при чём.
Подобные действия сначала вызывали много вопросов у моих знакомых, которых я знакомил с фотошопом (путаница со слоями, неочевидность действий), а потом отсутствие этого алгоритма вызывало вопросы у моих знакомых, которых я знакомил с гимпом (и которые до этого были знакомы с фотошопом)
Правда, это никак не опровергает мой тезис о том, что к фотошопу все просто привыкли: запомнили горячие клавиши, привыкли к иконкам и меню. И называют привычку удобством. Так-то оно так, вам (это я обобщённо) лично удобнее. Но про продуманный дизайн я бы утверждать не стал.
Готов обсудить это на отдельных примерах, но, боюсь, я не настолько сильно увлечён этой темой чтобы самостоятельно придумать ещё один.
И не нужно создавать новую и вставлять как новый слой.
Дизайн интерфейса тут ни при чём. Привычка пользователей, не более.
Это может быть логгирование (тут, наверное, единственное место универсальное) может быть повтор метода (без вариантов переноса кода), может быть какая-то логика (и тут круто увеличится зависимость одного класса от другого), может быть сложная логика с делегированием части обработки другому классу (программист который передаст, например, ну не знаю, репозиторий базы конструктор исключения должен быть жестоко наказан).
Из-за неуниверсальности обработки код получится сложнее: тут исключение само себя обрабатывает (чтобы узнать как читайти внутри), тут нет. Представьте себя читающим свой же код через 3 года. Хренпоймёшь и без этого, сложности и без этого достаточно. А тут ещё эта дополнительная сложность на пустом месте.
if(«Tommy».equals(name)){...}
Насколько я понимаю самым сложным модулем тут было распознавание текста (и то использовались встроенные библиотеки)
В остальном решение судоку выглядит задачей для второкурсника. Как-то не смотрится тут подпись google engineer. Google intern хотя бы.
Это был ответ на то, что надо закрывать P2P.
Выводы делаем сами — легального механизма для прикрытия торрента в оффшоре — нету. А самый-то сок в том, что он и не нужен. Производители вареза добирают свои деньги на корпоративных изданиях и на юзерах, которым не хочется/не можется возиться с поиском и выкачиванием нужного софта (знаю и таких). Производители гамезов добирают за счет большинства юзеров, которые, заценив достойный продукт, пойдут и приобретут его «для коллекции» или для возможности играть онлайн (например, на батлнете) (ессно, всякую бурду типа «Москва и мертвецы» никто покупать не пойдет, и правильно сделают). Музыканты вообще организовали «Круги», где выкладывают свои альбомы бесплатно, оставляя юзерам возможность напрямую (без посредничества копирастов) скинуть столько денег, сколько считают нужным (и, как показала практика, такая система ох как работает). Производители киноконтента основной доход имеют с проката, а предполагать, что народ перестанет ходить с друзьями и девушками в кино, потому что ту же фильму можно сличить — глупо, на все кассовые картины народ ходит в кинотеатр, а 20% того что личат — в русском прокате нету. Собсно, напрашивается вывод о том, что единственные, кого реально батхёртят файлообменники — это лютые копирасты типа РАО. Которые, заметьте, Шерлоков Холмсов тоже особо не снимают, да?
Вы либо неправильно перевели либо неправильно скопипастили.