Вот и наступил момент, когда chardet неправильно определил кодировку Win1251, решив, что это MacCyryllic и испортил файл. Я нашел из-за какого символа он так подумал — это была большая русская буква «С», которая на мак выглядит, символ тире.
Когда первый раз прочитал про электромагнитное воздействие на сайт (где-то месяц назад) — меня аж передернуло, бесят такие новости (высказывания)… Это все равно что, механическое воздействие на стихотворение. Им бы еще порвать мысль и заткнуть свою ерунду в прямую…
Видимо несколько факторов сразу сказывается.
1. Неудобный интерфейс программы. Если для той операции, которая равносильна рисованию креста на определенной строке маркером, необходимо что-то выбрать, зайти в меню еще что-то выбрать и нажать «да» — это конечно не правильный интерфейс. Если их основная задача в течение дня ставить «кресты», то интерфейс должен быть заточен под то, чтобы максимально быстро поставить крест.
2. Навык работы мышью недостаточный. Хорошие юзеры конечно могут схватить мышь и сделать три клика за пару секунд (а с маркера надо тоже еще снять колпачок и нарисовать крест).
То есть у них должен быть тогда планшетный пк и на проге должны быть такие элементы, на которых очень легко будет поставить крест одним тыком.
Я думаю «сцена в 3D-редакторе» и «Инструмент в 3D-редакторе» является очень даже понятным большинству. Вот уровень проверки действительно может быть непонятен. Проверка включается в себя: включение инструмента (установка его текущим со всем выполняемыми проверками объектов сцены при включении), смена режимов работы инструмента (например, выбор вершины полигона, перетаскивание вершины, выбор нескольких вершин), изменение данных самого объекта сцены при выполнении работы инструмента, зависимость работы от типа выбранных объектов.
Я не спорю, что можно написать автоматизированную систему проверки и это ускорит в дальнейшем все тестирования и проверку правильности результатов. Но есть одно но: на это нужно потратить не мало времени, а его не выделяют под эти задачи и плюс ко всему вопрос в количестве рабочей силы.
Еще добавлю, что проект очень большой уже, а программиста всего 1.5.
Дальнейшее обсуждение вопроса тестирования проекта будет лишь холиваром (причем Вашим с планами моего начальства).
Я конечно понимаю, что вы смогли расписать мои слова "свести к минимуму работу по кликам при проверке, но на это тоже надо тратить время и это рационально только тогда...", используя другие слова и модное слово «фейк». Но я уже написал, что это бывает очень не рационально.
Не понятны слова «3D-редактор» или «вершина»?
Объясню для вас подробнее:
допустим я на этот инструмент трачу один рабочий день вместе с отладками. Подготовить фэйковую сцену, сделать его автоматическую подгрузку и т.п. до самого этого инструмента займет около 2 рабочих дней. Это не нужно совсем, когда я на следующий день буду работать с совсем другой частью программы и мне не нужно будет грузить эту сцену вообще? Платят тут за скорость и результат, а не за идею правильно кодить. Так что расчитываю я для себя, нужна ли мне эта оптимизация в будущем или нет или когда потребуется тогда и напишу.
С версией wine 1.2 пробовал CS3, CS4 и CS5 Portable сборки с appz blogspot.
А с версией wine 1.3 фотошоп CS 4 работает плохо, а CS 5 даже не загружается до конца.
Цитата: «Как результат, практическая дистанция связи внутри помещений определяется в первую очередь потерями при проницании, а не при распространении в свободном пространстве, и поэтому ограничивается одной комнатой». http://ko.com.ua/jeta_mnogoobeshhayushhaya_polosa_60_ggc_44676
Автоматизировать проверку работы инструмента смещения вершины в 3D-редакторе, в котором нет возможности на данном этапе загрузить готовую сцену. Как?
Некоторые автоматизации я делал, например я сделал для себя давно прогу, которая рисует объекты, получая данные при дебаге в делфи программы. Наводишь курсор на переменную-массив точек и появляется хинт со значением переменной. Прога это перехватывает, забирает и рисует. Далее ты можешь навести на следующий и он тоже дорисуется и так далее. В общем графический такой дебаг переменных-полигонов.
Но не везде все можно автоматизировать, особенно проверку работы какого-то инструмента, который включается после загрузки ПО, создания сцены и т.п. Конечно можно свести к минимуму работу по кликам при проверке, но на это тоже надо тратить время и это рационально только тогда, когда уверен, что эту часть будешь еще долго отлаживать и дописывать.
Между излучателем и приемником скорее всего есть не только вы. Дело в том, что все зависит от антены излучателя. То есть если антенна на 360 градусов, то излучение идет по кругу в равной (почти) степени. А приемник, он всего лишь принимает, он как бы сказать "не затягивает в себя всю радиоволну" (а то бы и проблем с помехами не было никогда).
Ну и вот представьте, сидите вы на расстоянии метра от передающего (в данную долю секунды) устройства. Вот сколько ваше тело занимает от всего круга излучения? Я думаю процентов 10-15. То есть если очень грубо, то ваше тело (скорее верхие слои кожи на 60-ти ГГц'ах) на расстоянии метра возьмет на себя около 10% от мощности. Мощность передатчика у таких беспроводных устройств обычно около 20 мВт, то есть на вас будет расходоваться 2 мВт…
Дальше, прикинем телефон около уха на частоте 1800 Мгц.
Телефон находится вплотную к голове. Но антенна у него частично направленная в сторону от телефона, т.е. от головы. Хоть ваша голова и занимает около 40% от окружности, но попадает на нее скорее не более 10% сигнала. Мощность передатчика доходит до 1 Вт при 1800 Мгц (по некоторым источникам), значит на голову будет около 100 мВт, а то и меньше. На этой частоте сигнал будет гораздо слабее задерживаться жидкостями и проходить вовнутрь. Почти как в микроволновке, только можность маленькая очень…
Ксати, сравнивая работу телефона за день около головы и гарнитуры в ухе целый день (звонки + импульсный режим поддержания связи с телефоном), можно такими вычислениями выяснить, что от гарнитуры облучение будет в 10-100 раз меньше, чем от телефона.
Автокомплит несомненно необходимая вещь и без него сложнее намного, но в данном случае три буквы, точка, имя метода гораздо быстрее набирается нежели с использованием автокомплита и длинных названий. (и насколько бы человек тренирован не был, он все равно быстрее наберет короткое слово, чем более длинное, хоть и не целиком).
Завтра не забудешь, т.к. есть комментарий в объявлении переменной.
А если там лоадеры для нескольких тулов есть, то двух слов как бы недостаточно получается.
Минус только если ты в команде работаешь над данным модулем, т.к. разобрать код полностью состоящий из сокращений сложнее.
Программирую больше 3 лет один проект на делфи, иногда что-то переделываю. И вот мои наблюдения:
Полностью согласен, что чтобы не впасть в депрессию от выбора худшего зла (так как времени дается ограниченное количество), нужно начать писать код и возможно (как было как раз вчера), дойдя до нужного места, мысли придут сами собой.
А также лишние проверки работоспособности кода способны потратить чуть ли не 2 часа в день… А это четверть нормального рабочего дня. Но если их совместить в одну, то она выйдет гораздо короче, за пол часа все можно проверить и исправить.
И самое интересное, что когда на тебя давят и нужно сделать быстрее, то даже как-то не обдумывая начинаешь писать не проверяя. Быстро, по плану делать все доработки ничего не проверяя. А только потом в конце проверяешь и исправляешь синтаксис и другие мелкие ошибки.
Также недавно подумал: «надо быстрее написать, так что длинные переменные не для нас». Лучше я в декларации переменной добавлю комментарий, что она значит, а называться она везде будет CTL, а не CreateToolsLoaderObject. Благо в Delphi можно с контролом кликнуть по переменной (функции и т.п.) и посмотреть на ее объявление и быстро вернуться через ALT+Left.
В общем я за то, чтобы спланировать структуру ПО (функции, модуля), а дальше писать, запуская на проверку очень редко.
Добавляю дополнительную проверку между ними.
1. Неудобный интерфейс программы. Если для той операции, которая равносильна рисованию креста на определенной строке маркером, необходимо что-то выбрать, зайти в меню еще что-то выбрать и нажать «да» — это конечно не правильный интерфейс. Если их основная задача в течение дня ставить «кресты», то интерфейс должен быть заточен под то, чтобы максимально быстро поставить крест.
2. Навык работы мышью недостаточный. Хорошие юзеры конечно могут схватить мышь и сделать три клика за пару секунд (а с маркера надо тоже еще снять колпачок и нарисовать крест).
То есть у них должен быть тогда планшетный пк и на проге должны быть такие элементы, на которых очень легко будет поставить крест одним тыком.
Я не спорю, что можно написать автоматизированную систему проверки и это ускорит в дальнейшем все тестирования и проверку правильности результатов. Но есть одно но: на это нужно потратить не мало времени, а его не выделяют под эти задачи и плюс ко всему вопрос в количестве рабочей силы.
Еще добавлю, что проект очень большой уже, а программиста всего 1.5.
Дальнейшее обсуждение вопроса тестирования проекта будет лишь холиваром (причем Вашим с планами моего начальства).
Не понятны слова «3D-редактор» или «вершина»?
Объясню для вас подробнее:
допустим я на этот инструмент трачу один рабочий день вместе с отладками. Подготовить фэйковую сцену, сделать его автоматическую подгрузку и т.п. до самого этого инструмента займет около 2 рабочих дней. Это не нужно совсем, когда я на следующий день буду работать с совсем другой частью программы и мне не нужно будет грузить эту сцену вообще? Платят тут за скорость и результат, а не за идею правильно кодить. Так что расчитываю я для себя, нужна ли мне эта оптимизация в будущем или нет или когда потребуется тогда и напишу.
А с версией wine 1.3 фотошоп CS 4 работает плохо, а CS 5 даже не загружается до конца.
http://ko.com.ua/jeta_mnogoobeshhayushhaya_polosa_60_ggc_44676
Некоторые автоматизации я делал, например я сделал для себя давно прогу, которая рисует объекты, получая данные при дебаге в делфи программы. Наводишь курсор на переменную-массив точек и появляется хинт со значением переменной. Прога это перехватывает, забирает и рисует. Далее ты можешь навести на следующий и он тоже дорисуется и так далее. В общем графический такой дебаг переменных-полигонов.
Но не везде все можно автоматизировать, особенно проверку работы какого-то инструмента, который включается после загрузки ПО, создания сцены и т.п. Конечно можно свести к минимуму работу по кликам при проверке, но на это тоже надо тратить время и это рационально только тогда, когда уверен, что эту часть будешь еще долго отлаживать и дописывать.
Пришлось однажды канал вручную выставить наиболее свободный (на телефоне смотрел занятость каналов), чтобы лучше все работало.
Ну и вот представьте, сидите вы на расстоянии метра от передающего (в данную долю секунды) устройства. Вот сколько ваше тело занимает от всего круга излучения? Я думаю процентов 10-15. То есть если очень грубо, то ваше тело (скорее верхие слои кожи на 60-ти ГГц'ах) на расстоянии метра возьмет на себя около 10% от мощности. Мощность передатчика у таких беспроводных устройств обычно около 20 мВт, то есть на вас будет расходоваться 2 мВт…
Дальше, прикинем телефон около уха на частоте 1800 Мгц.
Телефон находится вплотную к голове. Но антенна у него частично направленная в сторону от телефона, т.е. от головы. Хоть ваша голова и занимает около 40% от окружности, но попадает на нее скорее не более 10% сигнала. Мощность передатчика доходит до 1 Вт при 1800 Мгц (по некоторым источникам), значит на голову будет около 100 мВт, а то и меньше. На этой частоте сигнал будет гораздо слабее задерживаться жидкостями и проходить вовнутрь. Почти как в микроволновке, только можность маленькая очень…
Ксати, сравнивая работу телефона за день около головы и гарнитуры в ухе целый день (звонки + импульсный режим поддержания связи с телефоном), можно такими вычислениями выяснить, что от гарнитуры облучение будет в 10-100 раз меньше, чем от телефона.
Завтра не забудешь, т.к. есть комментарий в объявлении переменной.
А если там лоадеры для нескольких тулов есть, то двух слов как бы недостаточно получается.
Минус только если ты в команде работаешь над данным модулем, т.к. разобрать код полностью состоящий из сокращений сложнее.
Полностью согласен, что чтобы не впасть в депрессию от выбора худшего зла (так как времени дается ограниченное количество), нужно начать писать код и возможно (как было как раз вчера), дойдя до нужного места, мысли придут сами собой.
А также лишние проверки работоспособности кода способны потратить чуть ли не 2 часа в день… А это четверть нормального рабочего дня. Но если их совместить в одну, то она выйдет гораздо короче, за пол часа все можно проверить и исправить.
И самое интересное, что когда на тебя давят и нужно сделать быстрее, то даже как-то не обдумывая начинаешь писать не проверяя. Быстро, по плану делать все доработки ничего не проверяя. А только потом в конце проверяешь и исправляешь синтаксис и другие мелкие ошибки.
Также недавно подумал: «надо быстрее написать, так что длинные переменные не для нас». Лучше я в декларации переменной добавлю комментарий, что она значит, а называться она везде будет CTL, а не CreateToolsLoaderObject. Благо в Delphi можно с контролом кликнуть по переменной (функции и т.п.) и посмотреть на ее объявление и быстро вернуться через ALT+Left.
В общем я за то, чтобы спланировать структуру ПО (функции, модуля), а дальше писать, запуская на проверку очень редко.