Category: it

Category was added automatically. Read all entries about "it".

Язвы и грабли CSV

CSV является стандартом де-факто для связи между собой разнородных систем, для передачи и обработки объемных данных с «жесткой», табличной структурой. Во многих скриптовых языках программирования есть встроенные средства разбора и генерации, он хорошо понятен как программистам, так и рядовым пользователям, а проблемы с самими данными в нем хорошо обнаруживаются, как говорится, на глаз.

История этого формата насчитывает не менее 30 лет. Но даже сейчас, в эпоху повального использования XML, для выгрузки и загрузки больших объемов данных по-прежнему используют CSV. И, несмотря на то, что сам формат довольно неплохо описан в RFC, каждый его понимает по-своему.

В этой статье я попробую обобщить существующие знания об этом формате, указать на типичные ошибки, а также проиллюстрировать описанные проблемы на примере кривой реализации импорта-экспорта в Microsoft Office 2007. Также покажу, как обходить эти проблемы (в т.ч. автоматическое преобразование типов Excel-ом в DATETIME и NUMBER) при открытии .csv.

Тем, у кого есть habrahabr-аккаунт, продолжение читать здесь Collapse )

Планирование программных разработок: делюсь опытом

Сегодня я хочу поделиться своей методикой планирования времени в разработке ПО, которая может быть очень быстро внедрена в небольших коллективах. Она очень проста во внедрении и «поддержке», чем показала себя очень эффективной.

В разное время, имея разные задачи и разные ограничения в управлении разработкой, я испробовал всё: от Microsoft Project и онлайн-сервисов до «самописных» решений. У каждого варианта есть свои недостатки и преимущества, и каждый из них заслуживает отдельной статьи. Сегодня речь пойдет о наиболее простом варианте — управление релизной разработкой в Excel-е.

Стоит сразу сделать несколько оговорок, чтобы предупредить ненужный флейм. Описываемое мною решение задачи подходит не для любой команды разработчиков, не для всех задач, не для любого класса программных проектов и не для каждой методики разработки. У него есть очевидное преимущество — может быть внедрено в нулевое время, не требуется никаких серверов, специального ПО, вообще ничего не требуется, кроме офиса. Правда, желательно майкрософтовского.

Итак, задача: упорядочить процессы разработки и поддержки продуктов компании при следующих условиях: основную часть задач составляют задачи длительностью от дня до трех недель, каждая затрагивает одного разработчика и одного тестировщика, разработка ведется на «релизной» основе — раз в неделю оттестированные модули включаются в очередную версию, каждая задача имеет конкретного внутреннего «заказчика» (менеджеры), которому , конечно, важна дата релиза, где появится его задача, общее число параллельных задач в производстве — от десяти до пятидесяти.

Как я уже говорил выше, я испробовал разные способы упорядочивания работы с такими проектами. Microsoft Project, например, не обладает достаточной степенью гибкости в управлении изменениями в плане, он предназначен для управления связанными в проект задачами, в которых их очередность объясняется их сущностью, а не порядком поступления или срочностью. Менять задачи в плане Project местами довольно неудобно, особенно, если это нужно делать часто. Да и вообще, для описанной задачи там всё неудобно.

Использовать сервисы web-based, как онлайновые, так и инсталлируемые на офисный сервер — лучше, потому что среди них выбор больше. Например, на прошлом месте работы я внедрил JIRA и мы ее очень активно использовали. Но минусов у нее хватает… Решения, которое нужно было мне, я среди них не нашел. Если кто-то может его подсказать, буду рад.

Возвращаясь к теме планирования задач с использованием Microsoft Excel.

Вот так выглядит план:




скачать шаблон

плана релизной

разработки в Excel


Итак, строки плана — задачи. Столбцы имеют следующую структуру:



На последующие недели заполняется желтая область, по прошлым неделям заполняется синяя область. Важно — в этом плане не указаны исполнители на задачу, если это нужно — просто добавляем столбец (в моем случае — не нужно, потому что исполнителям каждую неделю назначаются задачи из пула запланированных на эту неделю исходя из текущего состояния дел, это позволяет добавлять гибкости).

Внизу автоматически суммируются часы по всем задачам одного типа на неделю. Предполагается, что задачами одного типа занимаются программисты одной специализации, поэтому эти часы можно соотнести с доступными часами этих программистов. Как рассчитывать доступные для планирования часы — у каждого по-своему, например, можно заложить процентов 20 на исправление багов и на непредсказуемые срочные доработки, а 80 оставить для планирования.

Прошедшие недели «сворачиваем» минусиками сверху. Новые недели добавляем копированием предыдущей недели на следующий период. При копировании можно автоматически пересчитывать даты и номер недели.

Как только задача полностью выполнена, в блоке сделано ставим «Да». Настраиваем фильтр так, чтобы он НЕ показывал сделанные задачи (снимаем галочку с «да» в первом столбце).

Очень удобно, что при всем при этом работает фильтрация (Filter в «экселе») по строке 5, с заголовками. Это позволяет отвечать на вопросы:

  • Все задачи одного «заказчика» (фильтр по ЗАКАЗЧИК)

  • Все задачи на указанную неделю (фильтр по TOTAL части «План» недели)

  • Все сделанные задачи (фильтр по «сделано») и все задачи, которые еще предстоит сделать (фильтр по «сделано»)

  • И многое другое…


Как только задач становится больше 50, или задачи более сложны по структуре, или исполнителей много, или вы чувствуете, что эксель — слишком сложный или неподходящий инструмент для планирования, тогда нужно искать что-то более подходящее, благо на рынке довольно много готовых решений. Для относительно простых ситуаций (а их все-таки большинство) данного инструмента, IMHO, было бы достаточно... если бы не следующий абзац.

Теперь я опишу решение, которое для меня было бы идеальным. Я не нашел нигде реализации похожей концепции и буду рад, если кто-то может ее подсказать:

Строки — исполнители (люди, группы или целые отделы) , столбцы — время. Приходит новая задача — падает в «неразобранное». Я ее оттуда перетаскиваю на нужную строку, она либо раздвигает стоящие там уже задачи, либо перетаскиваю в хвост этих задач у конкретного исполнителя, и она цепляется в «водопад» после последней. Перетаскиванием я могу произвольно менять порядок очередных задач для исполнителя, но задачи для него всегда выстраиваются в «водопад». Либо могу переносить задачу с одного исполнителя на другого, тогда перестраивается «водопад» у обоих. После нажатия на кнопку "Применить " мне демонстрируется перечень изменений (заказчик — задача — старая дата — новая дата) и по нажатию на кнопку «Разослать» происходит уведомление заказчиков и исполнителей об изменениях. Текущая задача может быть в любой момент прервана, ее остаток может быть пересмотрен по времени и поставлен куда-нибудь в будущее или перенесен в блок «неразобранное» или вообще удален. Что происходит в этом случае? Все следующие задачи сдвигаются.

Вот иллюстрация:











Подарок всем использующим французский язык

Я подготовил раскладку, которой можно смело заменить текущую английскую. С ее помощью можно писать по-французски, не калеча клавиатуру. Сразу скажу, я поисследовал вопрос и на всех форумах советуют ставить испанскую, типа там все есть. Но в испанской начинают криво работать привычные нам клавиши — например, тот же слэш у меня начал выдавать что-то левое.

Выложенная мною раскладка имеет ряд преимуществ, чтобы оставить ее у себя, даже, если вы французские диакритические знаки вводите редко или не вводите совсем.

Раскладка включает в себя все дополнительные символы раскладки Ильи Бирмана. Раскладкой Ильи я пользуюсь давно и без нее даже уже неудобно даже. Самое ценное в ней для повседневного применения — это длинные тире (—, вводятся правый Alt + дефис) и кавычки («», вводятся правый Alt плюс клавиши "<" ">"). Там довольно много всякого дополнительного добра, но о вводе диакритических знаков Илья не позаботился. Разве что только для ввода русских ударений. Этого не хватает для ввода французских текстов, конечно.

Итак, что у меня появилось:

Ctrl-' (контрол-кавычка) плюс:
  • «e» дает «é», «Е» дает «É»
  • «c» дает «ç», «C» дает «Ç»

    Ctrl-` (контрол-ё) плюс:
  • «a» дает «à», «A» дает «À»
  • «e» дает «è», «E» дает «È»
  • «i» дает «ì», «I» дает «Ì»
  • «o» дает «ò», «O» дает «Ò»
  • «u» дает «ù», «U» дает «Ù»

    Ctrl-^ (контрол-шифт-6) плюс:
  • «a» дает «â», «A» дает «Â»
  • «e» дает «ê», «E» дает «Ê»
  • «i» дает «î», «I» дает «Î»
  • «o» дает «ô», «O» дает «Ô»
  • «u» дает «û», «U» дает «Û»

    Таким образом можно вводить тексты с диакритическими знаками довольно шустро. Например,

    Je demande pardon aux enfants d'avoir dédié ce livre à une grande personne. J'ai une excuse sérieuse... même les livres pour enfants...sans la mârcher.. Il était comme ça..

    Скачать дистрибутив можно здесь: http://raliev.ru/download/en-fr/en-fr.zip

    Все просто, запускаете, и появляется раскладка. За деталями, если какие проблемы, можно посмотреть сайт Ильи Бирмана, там все необходимое есть.

    Про сегодняшние проблемы с Chronopay

    Мне сегодня не переставая сыпятся звонки от знакомых и друзей на эту тему. Напишу тут, чтобы развеять все вопросы. Я в Chronopay — руководитель по разработкам. Упрощенно говоря, руковожу разработкой процессингового софта и системами внутренней автоматизации. Мы делаем софт, который после передаем в эксплуатацию. В эксплуатации сегодня «пожар», как это всем видно из новостей. Итак, о проблеме. У нас довольно сильно разграничен доступ к информации, поэтому я могу прокомментировать лишь то, что мне видно и понятно.

    В сети есть некий сайт, не буду приводить его тут, на котором выложили якобы кусок нашей базы. Надеюсь, всем понятно, что доказать отсутствие утечки невозможно в принципе, в то время как доказать утечку проще. Так вот, насколько известно мне, доказательств утечки базы ни у кого нет. Карты воруют много где, и тут я своих коллег поддержу. Какая-то база использована для компрометации Chronopay. Разумеется, многие из перечисленных карт и в нашей базе есть.

    Но при этом выложенный якобы кусок нашей базы вызывает вопросы.

    CVC2 — у нас просто нет этой информации, вообще нет. В выгрузке ее быть не может.

    Номер карты — с какого перепугу там пробелы? какой кривизны должны быть руки у разработчика, чтобы сохранять в базу транзакций номер карты в том виде, в каком его ввели, да еще и неправильный (там есть ошибочные номера). И, конечно, он шифруется.

    Expiredate не хранится в виде двух отдельных полей. А в выгрузке они так представлены.

    Есть предположение, что эта база — перехваченные где-то формы ввода платежных реквизитов, выдаваемые за нашу базу. Это невозможно доказать, ни опровергнуть, но других объяснений, откуда взялась база с CVC2, я не вижу.

    Кстати, известно, что злоумышленники воруют с реальных банкоматов пин-коды т.н. «скиммерами». Фактически, это утечка с банкомата конкретного банка, но, к сожалению, такие утечки невозможно предотвратить (не ставить же охрану рядом с каждым банкоматом). В сети такое более контроллируемо, но все равно есть масса подобных способов (например, кейлоггеры). Замыкать подобные проблемы сразу на банк (в случае банкомата) или на процессора (в случае кейлоггеров), не доказав — не совсем этично. Хотя, конечно, с точки зрения потребителя — логично.

    Ну и сам факт якобы «утечки» данных не был бы заметен, если бы не кража домена chronopay.com, что действительно было. Отсюда и дефейс с ложной информацией, и проблемы с другими сервисами, где был задействован этот домен. Сейчас этим всем занимаются как технари, так и соответствующие органы.

    Ну вот пока все, что я знаю. Я оговорился в начале — что пишу только про то, что знаю. А те, кто знают больше — сейчас «тушат пожар». Как потушат — разберусь и я сам. Может, напишу что.

    Искусство программирования под Unix (и не только). Часть шестая, «правило кодоэкономии»

    Я продолжаю цикл статей, посвященных некоторым простым правилам разработки под Unix «по версии Эрика Реймонда», которые, по моему глубочайшему убеждению, могут быть распространены на любые другие операционные системы. Я уже рассказывал в первых трех частях о правилах модульности, ясности, композиции, разделения и простоты. Сегодня дело дошло до шестого правила —



    Правило кодоэкономии: разрабатывайте большие программы только при наличии объективных причин это делать Collapse )

    Искусство программирования под Unix (и не только). Часть четвертая, «правило разделения»

    Я продолжаю цикл статей, посвященных некоторым простым правилам разработки под Unix «по версии Эрика Реймонда», которые, по моему глубочайшему убеждению, могут быть распространены на любые другие операционные системы. Я уже рассказывал в первых трех частях о правилах модульности, ясности и композиции. Сегодня дело дошло до четвертого правила —

    Правило разделения: отделяйте правила от механизма, а интерфейсы от движка («бизнес-логики») (Rule of Separation: Separate policy from mechanism; separate interfaces from engines)

    Collapse )

    Искусство программирования под Unix (и не только). Часть первая, «правило модульности»

    Последние лет десять я ищу на рынке программистов, делаю с ними большие и маленькие подвиги, преимущественно в области веб-разработок. Но, к сожалению, все меньше и меньше находится достойных кандидатов. Работают годами над одними и теми же задачами, клонируя имеющиеся решения и их недостатки. Спрашиваешь про то, что достиг — а в ответ рутинные, банальные вещи. Автоматизация окошек — вот то, чем занимается большинство из таких программистов. А на действительно сложные задачи как было мало специалистов, так и остается по сей день.

    Unix-программисты выделяются на фоне этих «автоматизаторов окошек». В мире открытого ПО каждый может попробовать свои силы и в разработке системного «софта», и в сложных прикладных решениях. Достижения таких людей в мире открытого ПО доступны всем, и для меня они порой заменяют любые рекомендации. Потому что их работу видно.

    Есть ряд книг, которые, на мой взгляд, являются своеобразными «библиями» для тех, кто решил связать свое будущее с разработкой ПО. С одной из них я хотел бы начать цикл статей. Это книга Эрика Рейнмонда, «Искусство программирования под Unix». Я бы рекомендовал эту книгу не только тем, кто выбрал для себя открытые операционные системы. В основе лежит довольно универсальная философия, пригодная абсолютно всем, связавшим свою профессию с программированием.

    Эрик Реймонд выделяет 17 правил этой «философии». Я буду посвящать по одной заметке на каждое правило. Я постараюсь изложить эти концепции в максимально понятной, упрощенной и популярной форме, насколько это будет возможно.

    Collapse )

    Flash на айпаде

    Накипело - повстречал товарища, он похвалился, что для одного крупного бренда они отдельым проектом переделывали флэш-вставку на JavaScript, потому что у одного из шефов сверху есть айпад, а там флэш не крутится.

    Да, на айпаде в браузере нет флэша. То есть, все флэш-баннеры заменяются пустыми дырами.

    Классическое объяснение этого пользователями - эппл не хочет пускать на свои устройства скриптовые языки, позволяющие создавать программы, игры в обход производителя платформы.

    Классическое объяснение Эппл - блюдем качество, а флэш - сырой. Когда сделают нормально - велкам.

    Истина же где-то посередине и еще кое в чем, что обычно не упоминается. Флэш рассчитан на следующие возможные варианты ввода информации:
    1) движение мыши над областью без клика
    2) клик + движение (драг-н-дроп)
    3) даблклик и обычный клик
    4) нажатия на клавиатуре, когда фокус у флэша
    5) нажатия + клики + движения (например, драг-н-дроп с зажатым шифтом или стрелками управляешь, кликами стляешь в играх)

    Айфон или айпад из перечисленного добавляет непопулярный на десктопах "долгий клик", но напрочь лишен всех перечисленных, кроме второго и третьего. Это значит, что львиная доля флэш-роликов рпботать просто не будет. понимать наведение мышью через тачскрин - совсем непростая инженерная задача. А среднему юзеру макоси знать, что их устройство работает криво с веб-страницами хуже, чем знать, что не работает вовсе.

    Вот пишут - а как же флэш-видео, это же гигантский рынок, подавляющее большинство всех мультимедийных вставок приходится на него. А вот работает оно на айпаде. Не всякое, а только то, что в стандарт html5 укладывается. Ютьюб и Ваймио быстренько превели свои плейеры на html5 compatible, а рутьюбы и подобные ему сервисы - переведут в ближайшее время. Так что нет здесь проблемы.

    (no subject)

     У меня одна из рубашек -   Louis V. Gerstner. Бренд такой. Покупал в Alfred Muller. Решил посмотреть, кто такой Луис Герстнер. Оказалось, что это генеральный директор IBM c 1993 года по 2002 года. И здесь АЙТИ!

    похож на ботаника.

    В догонку про QSOFT - для техногиков, у остальных будет взрываться мозг. Впрочем, он будет у всех..

    Уж раз пошла такая дудка. Они на сайте пишут про связной.ру:

    Реализована сложная модель данных хранения информации по товарам, стоимости и остаткам, которые зависят от региона. Для каждой товарной категории предусмотрены отдельные наборы свойств товара.

    Она действительно сложная. И это не плюс. В битриксе есть такое понятие инфоблоков. Для тех, кто не знает, это такая виртуальная таблица, работа с которой осуществляется не через SQL, а посредством API Битрикса. Подход, впрочем, не самый плохой — ORM есть во многих фреймворках. Понятно, что такая прослойка в форме API позволяет делать базовые вещи, но как только дело доходит до сложных выборок, API уже не помогает. Так вот, в базе Связной.ру несколько сот рубрик, несколько десятков тысяч товаров, которые хранятся в информационных блоках вместе со всякой мелкой шнягой. Это еще полбеды. Но вот какой злой ум придумал хранить цены там же, это нужно спросить у кусофта. Цен там много — для каждого региона и товара своя цена, в итоге выходит около полусотни тысяч записей. Да, и все это еще с контролем версий — на многие элементы велась история изменений. В итоге у нас и цены, и товары, и категории лежат в одной физической таблице на несколько сот тысяч записей. Теперь представим, что из себя будет представлять сложный запрос, отображающий список товаров с ценами из выбранных разделов — он джойнит эту огромную таблицу несколько раз.

    Потом эта система с инфоблоками рушит мозг программистам и делает из них недопрограммистов, если они вовремя не хватаются за голову и не ставят ее на место. В битриксе нормальное дело не только хранить флаги и числа в VARCHAR(255), но и хранить данные разных типов в одной колонке таблицы. Специально, чтобы никакие индексы человеческие по этому построить было нельзя. Так вот, когда дело доходит до создания специальных таблиц, битриксовые программисты кусофта не долго думая создают такие же кривые структуры данных.

    То, что картинки при необходимости масштабируются эксплорером — это ерунда. Ведь заказчик не заметит.

    То, что типовая страница собирается 4-5 секунд, тоже нормально. Там же всего от нескольких сотен до тысячи запросов. Как бороться? просто увеличиваем кэш. Да, с кэшем запросов всего 50. Тормозит? Отключим статистику. А, так 1000 запросов из-за статистики?..

    Сегодня прособеседовал двух программистов. С сожалением вижу, что люди хотят больше денег, а умеют только формы автоматизировать. Ну и простые выборки из базы данных в HTML облачать. Некоторые добились чуть большего — освоили JQuery. А проектировать умеют единицы. Думать умеют единицы. Когда даешь задачу на придумывание подхода к нестандартной задаче — все, стоп, этого в библиотеках готовых нет, это сделать нельзя.

    Мне нужно обработать базу в несколько сот тысяч записей. Надо нормализовать и по ней сделать некоторую аналитику, причем нужно вырабатывать гипотезы, проверять, корректировать курс, дорабатывать скрипты, смотреть на результаты, проверять, ставить новые гипотезы, по ходу выдавать предложения, влияющие на продажи. Нужно уметь делать сложные запросы быстро, направлять результат на тут же написанный скрипт-обработчик текстовой информации, позволяющий тут же сделать выводы и скорректировать работу. Нужен исследователь-программист. Присылайте мне таких людей, нужны очень, а?