^FOx,y — отступ от левого верхнего края, принимает значение от 0 до 32000
А измеряются x и y в единицах, заданных последней командой ^MU. По умолчанию это точки, чей размер зависит от разрешения принтера. Для создания этикеток, одинаково выглядящих на принтерах с разным разрешением, удобно работать в миллиметрах, ^MUm.
При этом стоит всегда возвращать единицы к точкам в конце этикетки: ^MUd^XZ.
Это потому, что драйверы Zebra, когда транслируют печать из обычного приложения в ZPL, обнуляют все персистентные параметры, а единицы измерения обнулить забывают. (Писали про это в поддержку; не удалось попасть на кого-то, кто понял бы, о чём мы вообще.)
В результате драйвер выдаёт команду напечатать что-то по координатам, скажем, (1000, 500), думая, что это в точках. Но поскольку последний заданный режим был в миллиметрах, картинка рисуется на метр вправо от границы этикетки, и этикетка выходит пустой.
При этом в режиме без поворотов, отражений и справаналевости ^FO определяет левый верхний угол результирующей строки/картинки/штрихкода. ^FT определят левый нижний. Иногда удобно одно, иногда другое.
^FDdata — символ начала текстового поля
Нет, это символ начала поля данных. Эти данные могут принадлежать чему угодно, не только текстовому полю. В частности, это может быть наполнение штрих-кода.
^FS — символ конца строки
Нет, это символ конца определения поля, начатого ранее. Концы строк сами по себе никак не маркируются.
Полезно помнить, что ^FB — уникальная команда, которая недокументированно игнорирует единицы измерения, заданные в ^MU, и трактует все свои измерения как заданные в точках.
Полезно также помнить, что если текст не уместится в maxLines, то весь не уместившийся текст будет печататься поверх последней строки, снова и снова, пока не кончится.
Тема ^TB, улучшенной версии ^FB, не раскрыта!
По какой-то причине, некоторые принтеры не хотят воспринимать последний параметр после ^BQ, но воспринимают его после ^FD:
Потому что документировано, что для ^BQ строка данных ^FDдолжна начинаться с дескриптора, описывающего характеристики QR. Если его опустить, могут быть потеряны первые три символа данных.
Мне кажется, что проблема вот тут
this.commit("setCategories12345", categories);
Если в названии мутации написать людей текст, то он будет комплимент, но не будет работать. Это — отсутствие типизация. Почему бы не указывать вместо строкового литерала именно член класса?
Красиво. Если продолжать погружаться в LQR, то для оценки скорости надо построить линейный стационарный наблюдатель (фильтр Калмана), так как это близкие родственники.
Тоже в этом году решил отказаться от LEGO Mindstorms в пользу Arduino. Только будем использовать не оригинальный Arduino, а конструктор Makeblock. Он подороже обойдётся, но на порядок прочнее и проще в сборке разных конструкций.
Известно ли Вам что-нибудь о предстоящих соревнованиях в крае? На сайте Russian Robotics указан Сочи в ноябре, а будет ли традиционное в Новороссийске?
Интересные мысли, но создается впечатление, что автор не знаком с работами классиков Agile, такими, как Кент Бек, Мартин Фаулер, Хенрик Книберг. Не говоря уже о каких-либо более сложных работах в этой области. Успешно применяю, то что можно обощить, как Agile уже около 10-ти лет.
1. Нет критериев эффективности конечного результата.
Как так? Гуглите по запросу «метрики Agile» и найдите, то что наиболее подходит для вас!
2. Непредсказуемость.
Как раз Agile направлен на то, что б получить результат. Но результатом в данном случае является то, что надо бизнесу, причем с точки зрения бизнеса. Мы принимаем за аксиому, что бизнес постоянно изменяется и это требует внесения изменений в ПО. Пример простой, есть компания которая продает скажем ноутбуки, и тут бизнес принимает решение, что нужно продавать еще и планшеты, потому что это перспективный рынок. До того, как появились планшеты бизнес ни на каком проектировании не мог предположить, что нужно такие требования к разработке выдвигать. Понятно, что нужно будет значительную часть системы переписать, но иначе бизнес упустит перспективную возможность, и об этом на этапе проектировании ничего не было известно. При этом, используя метрики и проектирование, можно в течении нескольких дней сказать сколько это времени займет и сколько будет стоить. Что очень хорошо для бизнеса. В Agile бизнес-решения принимает бизнес, а технические решения принимают — программисты. Ответственность в Agile должна приниматься всей командой, включая бизнес, иначе аджайла не будет. Так что аджайл в этом смысле с одной стороны предсказуем — из 20 спринтов последнего проекта, не правильно оценили время мы всего в двух и то из-за полного отсутствия информации.
У меня настроен кросс пост в твиттер, жж, и другие площадки с анонсом и ссылкой на полный пост. Индексация новой записи быстрая. Да и я обращал внимания на дату индексации моей записи и копии на ГС. Я быстрее.
Отдельное спасибо за
А измеряются
xиyв единицах, заданных последней командой^MU. По умолчанию это точки, чей размер зависит от разрешения принтера. Для создания этикеток, одинаково выглядящих на принтерах с разным разрешением, удобно работать в миллиметрах,^MUm.При этом стоит всегда возвращать единицы к точкам в конце этикетки:
^MUd^XZ.Это потому, что драйверы Zebra, когда транслируют печать из обычного приложения в ZPL, обнуляют все персистентные параметры, а единицы измерения обнулить забывают. (Писали про это в поддержку; не удалось попасть на кого-то, кто понял бы, о чём мы вообще.)
В результате драйвер выдаёт команду напечатать что-то по координатам, скажем,
(1000, 500), думая, что это в точках. Но поскольку последний заданный режим был в миллиметрах, картинка рисуется на метр вправо от границы этикетки, и этикетка выходит пустой.При этом в режиме без поворотов, отражений и справаналевости
^FOопределяет левый верхний угол результирующей строки/картинки/штрихкода.^FTопределят левый нижний. Иногда удобно одно, иногда другое.Нет, это символ начала поля данных. Эти данные могут принадлежать чему угодно, не только текстовому полю. В частности, это может быть наполнение штрих-кода.
Нет, это символ конца определения поля, начатого ранее. Концы строк сами по себе никак не маркируются.
Полезно помнить, что
^FB— уникальная команда, которая недокументированно игнорирует единицы измерения, заданные в^MU, и трактует все свои измерения как заданные в точках.Полезно также помнить, что если текст не уместится в
maxLines, то весь не уместившийся текст будет печататься поверх последней строки, снова и снова, пока не кончится.Тема
^TB, улучшенной версии^FB, не раскрыта!Потому что документировано, что для
^BQстрока данных^FDдолжна начинаться с дескриптора, описывающего характеристики QR. Если его опустить, могут быть потеряны первые три символа данных.Мне кажется, что проблема вот тут
this.commit("setCategories12345", categories);
Если в названии мутации написать людей текст, то он будет комплимент, но не будет работать. Это — отсутствие типизация. Почему бы не указывать вместо строкового литерала именно член класса?
http://robotsbigdata.com/docs-arduino-timer.html
Есть в ардуиновском library manager, так что даже с гитхаба качать ничего не надо.
http://playground.arduino.cc/Code/Timer1 Все остальное — костыли
3.2 дюйма -1354 рубля — бесплатная доставка
4.3 дюйма — 2998 руб — бесплатная доставка
7 дюймов — 5300 -бесплатная доставка
Но это я так навскидку. Если поискать, то есть варианты, и даже в Росии. Где то натыкался
Известно ли Вам что-нибудь о предстоящих соревнованиях в крае? На сайте Russian Robotics указан Сочи в ноябре, а будет ли традиционное в Новороссийске?
На муське то же, но без подробностей с google translate
1. Нет критериев эффективности конечного результата.
Как так? Гуглите по запросу «метрики Agile» и найдите, то что наиболее подходит для вас!
2. Непредсказуемость.
Как раз Agile направлен на то, что б получить результат. Но результатом в данном случае является то, что надо бизнесу, причем с точки зрения бизнеса. Мы принимаем за аксиому, что бизнес постоянно изменяется и это требует внесения изменений в ПО. Пример простой, есть компания которая продает скажем ноутбуки, и тут бизнес принимает решение, что нужно продавать еще и планшеты, потому что это перспективный рынок. До того, как появились планшеты бизнес ни на каком проектировании не мог предположить, что нужно такие требования к разработке выдвигать. Понятно, что нужно будет значительную часть системы переписать, но иначе бизнес упустит перспективную возможность, и об этом на этапе проектировании ничего не было известно. При этом, используя метрики и проектирование, можно в течении нескольких дней сказать сколько это времени займет и сколько будет стоить. Что очень хорошо для бизнеса. В Agile бизнес-решения принимает бизнес, а технические решения принимают — программисты. Ответственность в Agile должна приниматься всей командой, включая бизнес, иначе аджайла не будет. Так что аджайл в этом смысле с одной стороны предсказуем — из 20 спринтов последнего проекта, не правильно оценили время мы всего в двух и то из-за полного отсутствия информации.
Дольше и дороже.
Тут я просто ссылку на статью дам, которая все объясняет http://blog.scrumtrek.ru/2011/03/agile-waterfall.html
Настоятельно советую прочесть всем тем, кому этот пост показался интересным!