Как стать автором
Поиск
Написать публикацию
Обновить

Qt4 + Криптография

Когда я начинал изучать Qt4, я восхищался этим фрэймворком и часто вступал в противостояния холиваров и различных споров вроде «Qt vs ...», защищая Qt. В одном из таких споров мне задали вопрос касающийся, криптографии в Qt. В ответ я привёл такие возможности Qt, как QSSLSocket, а так же возможность использования сторонних Crypto API, т.к. с криптографией в Qt дело не имел.

Как-то мне пришлось написать программу, использующую шифрование как в сети, так и при записи в файл. Я начал подбирать CryptoAPI и выбор пал на OpenSSL. После нескольких часов изучения API, я понял, что просто так с этим не разобраться и возможно есть другие пути привязки CryptoAPI к Qt. Погуглив, я нашёл интересный биндинг под суровым названием QCA.
Читать дальше →

Домашняя торрент качалка из Opensuse + rtorrent + samba

Я понимаю, что это все можно быстро найти в сети, но я решил все собрать в одном месте чтобы вы не тратили ваше время на поиск)
Есть у меня старый компьютер следующей конфигурации Pentium 4 2 GHz + 256 Mb RAM + 80 Gb HDD + Opensuse 11. Выбрал я эту систему так как ее приходиться испоьзовать по работе и она для меня самая близкая и знакомая, да и плюс всегда есть у кого проконсультироваться.
У меня есть пару соседей по квартире, с которыми я ее снимаю, захотелось мне раздавать всем интернет сделал я сначала простейшую настройку iptables прописыванием нескольких строк:

pppd call <имя вашего провайдера> //Стартует Интернет который идет через впн, настройки можно найти в сети.
echo 1 > /proc/sys/net/ipv4/ip_forward // Главное это включить форвардинг
iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o ppp0 -j MASQUERADE // Включаем маскарад
iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o eth2 -j MASQUERADE


Так как мой локальный провайдер дает динамические локальные адреса то пришлось делать маскарад. PPP0 — это интернет интерфейс, а eth2 это интерфейс локальной сети провайдера.
Все это я записал в файл inet, дал ему права на выполнение и сохранил его в /usr/sbin. Затем чтобы маскарад работал всегда при включении сервера я создал файл after.local в папке /etc/init.d, в этом файле была только одна строка /usr/sbin/inet.

Дальше больше, мне захотелось не просто раздавать интернет, а также постоянно скачивать и раздавать торренты, благо интернет у меня безлимитный хоть и не очень скоростной 512kb/sec.
Здесь все оказалось сложнее чем я думал, хотя может у меня просто руки кривые, тем не менее у меня все никак не хотела работать связка wtorrent+rtorrent. Сколько я не бился, максимум, что мне удалось добиться это только запуска того и другого по отдельности)
Я решил пойти другим путем и настроить rtorrent+webui, нашел замечательный мануал тут. Да кстати, ЭТО ОЧЕНЬ ВАЖНО!!! Нельзя ставить rtorrent из репозитариев, там он (как я понял) в целях безопасности собран БЕЗ поддержки xml-rpc, так что надо собрать его самому из исходников, ну это просто. Попутно мне пришлось разобраться с установкой и настройкой сервера apache, а также прикруткой к нему xml-rpc.
Пару слов о настройке rtorrrent'a я настроил его так чтобы он каждые 5 секунд мониторил определенную директорию на диске и при появлении там торрент файла начинал закачку.
Ну вот вобщем про торренты и все.

Дальше больше и я захотел сделать из своего сервера еще и сетевое хранилище, чтобы я и все мои соседи видели его как сетевой диск в виндовс. Хочу сказать что до этого момента я себе очень смутно представлял что такое самба и с чем его едят, но пару часов в гугле, и чтение манов мне помогло.
Так что вроде все) Если есть вопросы то пишите.

Вуду mod_rewrite и умные превьюшки

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

Традиционно программисты на PHP следуют наиболее легким путем. Создается файл preview.php, в котором записывается алгоритм преобразования картинки, URL которой передается в запросе, с помощью функций GD (а именно imagecopyresampled) и вывода его в браузер с выдачей соответствующих http-заголовков. Затем в HTML-коде такая масштабированная картинка вызывается с помощью примерно такого кода: <img src=«preview.php?image=test.jpg&width=100»… />
Примеры кода не привожу, поскольку их можно взять практически в любой CMS.

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

При создании своего скрипта интернет-магазина, а затем и своей CMS я попытался найти другой путь. Вот что получилось.
Читать дальше →

Microsoft BizTalk Server глазами новичка

Недавно по ходу работы мне пришлось познакомится с серверной технологией BizTalk от Microsot.
И мне очень не хватало внятного объяснения, что это, зачем и почему. Потратив некоторое время на разбирательство пришел к выводу, что не так страшен черт, как его малюют, и даже оказался сам способен (как мне кажется) написать подобную статейку.
Я не буду здесь приводить технических деталей или переписывать туториалы из Microsoft. Я хочу просто объяснить что это и зачем, что означают базовые понятия, что (надеюсь) поможет существенно облегчить дальнейшее ознакомление/изучение в MSDN (ну или отказаться от него, если не подходит/не нравится).
Читать дальше →

Twitter для занятых людей

image
Тратишь много времени на чтение twitter-лент своих друзей и знакомых?

Не волнуйся. Теперь ты можешь ускорить этот процесс при помощи нового сервиса Twitter For Busy People. Данный интерфейс разработан командой Bluejava.

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

Piccy.info - Free Image Hosting

Из рекламного объявления:

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

Поэтому мы создали данный сайт, для чтобы видеть каждого из знакомых (до 500 человек) на одной странице. Легким движением мыши мы можем увидеть последнее сообщение каждого. И если нам нужна полная история контакта – достаточно лишь кликнуть на нем.

Шпионские страсти, или как сделать запись разговора качественно и надежно

Я начал играть в шпионов с месяца два назад, когда с меня стали требовать долги, которых я не делал. В кризис все потихоньку сходят с ума, сошли и мои бывшие работодатели. Впрочем, история грязная и вряд ли заслуживает внимания читателей. Обрисую лишь основные моменты.

1. Меня дискредитировали в глазах других людей.
2. В приватном разговоре со мной мне сообщили, зачем и почему они это сделали.
3. Предстояло еще немало приватных разговоров на эту тему.

Хотя, как объяснил мне адвокат, запись разговора без разрешения обеих сторон в суде уликой не является, но лишней она не будет. Кое-что в памяти может не отложиться… Как в том старом анекдоте: «А поможет?» – «Не повредит». Да и суду покажем, если что...

Диктофон? Разумеется! Мобильный телефон – первое, что пришло в голову. Провел дома эксперименты. Чтобы получилось хоть что-нибудь вразумительное, его нужно держать в руках перед собой. В кармане получается полнейшая неразбериха.

Стал искать варианты. Выяснил много для себя интересного. Джеймс Бонд отдыхает рядом с нашими умельцами… Оказывается, московская фирма «Телесистемы» попала… в Книгу рекордов Гиннеса. В 2004 году выпускаемый московскими электронщиками цифровой диктофон Edic-Mini A2M официально признан самым легким и миниатюрным в мире. Но с тех пор появились модели еще меньших размеров.

Серия Edic-Mini Tiny имеет размеры начиная от 6х25х31 мм и вес от 6 грамм. Запись ведется на встроенную флеш-память или карту xD Picture. А длительность записи при этом поражает – до 1200 часов. Главное, что звук получается четким и громким, хотя при моих «тестах» диктофон упал на дно внутреннего кармана пиджака. Авторы миниатюрного шпионского устройства утверждают, что максимальная дальность нормальной чувствительности – 9 метров. Без подзарядки малютка работает до 420 часов.
Включать диктофон можно голосом или по таймеру в выбранное время – для шпиона незаменимые функции. И чужой человек записанное не прочтет – запись закрывается паролем.

Самые маленькие диктофоны могут только записывать. Те, что побольше, – еще и воспроизводят. Мне достаточно было первого. Edic-mini Tiny снабжены встроенным интерфейсом USB. Подключил к ПК, переписал – и можно слушать и редактировать запись средствами ПК. Кстати, загружает на ПК малютка информацию предельно быстро – скорость обмена заявлена в 5,5 Мбод, похоже, так оно и есть.

Качество записи – потрясающее, голос воспроизводится «как живой», совершенно без искажений. Можно даже стереозапись делать.

Разумеется, такая «игрушка» стоит недешево. Но честь мне оказалась дороже, тем более что ничего, что могло бы сравниться с описываемой аппаратурой и по качеству, и по размерам, я найти не сумел ни за какие деньги. Тут как бы и перехвалить не хочется, стал искать недостатки… Но после того, как на следующей приватной встрече малютка голосом врагов «проболталась» мне даже о том, чего я не слышал… Говорили тихо и между собой – «засек»! Расхотелось о недостатках. Дорогой, вот. Денег своих стоит.

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

Память можно всерьез экономить. Голосовое управление позволяет пропускать паузы, при этом их длительность на ПК можно восстановить. Все необходимое ПО прилагается.

Хотел узнать у уважаемых Хабралюдей, имел ли кто-либо дело с нашей судебной системой на предмет использования «нелегальных» записей. Мой адвокат, послушав запись, ухмыльнулся – довольно и потер руки – хищно, но ничего обещать не стал. Судебная процедура запутана донельзя… Но я что-то стал ходить с поднятым кверху носом. Такая штука в кармане! Кого хочешь, обличу. Стра-ашно?

Программист и ошибки — актуально во все времена ;-)

Годы бегут, компьютеры становятся мощнее, листинги программ длиннее, а программисты возятся всё с теми же разновидностями ошибок, как и пару десятков лет назад :)

В книге «Принцип Питера, или дела идут вкривь и вкось» Лоуренс Дж. Питер пишет в главе «Электронная некомпетентность», посвящённой компьютерам:
Компьютеры бесподобны: за несколько минут они могут совершить такую ошибку, которую не в состоянии сделать множество людей за многие месяцы.

Человечество имеет уже достаточно примеров, наглядно демонстрирующих, к каким последствиям приводят ошибки компьютеров. Откуда же они берутся и на какие типы делятся? Вот давайте сегодня с этим и разберёмся, а в качестве примеров я буду использовать любопытные факты, которые уже стали частью истории

Типы ошибок

Тип 1. Ошибки в программном комплексе, допущенные при разработке и не обнаруженные при его тестировании


  • В «Справочнике Microsoft Works» и интерактивной помощи пакета интегрированной обработки информации Works 2.0 функция ЕСЛИ описана как
    ЕСЛИ (Условие, ЗначениеЛожь, ЗначениеИстина)
    Однако в действительности работа данной функции должна иметь следующий вид:
    ЕСЛИ (Условие, ЗначениеИстина, ЗначениеЛожь)
    В «Руководстве пользователя Microsoft Works для Windows» пакета Works 3.0 эта ошибка исправлена.
  • В русифицированном варианте Norton Utilities (версия 7.0, фирма Symantec) в утилите форматирования sformat при задании опции:
    Системные файлы: [Не ставить…]
    при форматировании выдаётся сообщение:
    Системные файлы: Ставить
    и наоборот, при задании опции:
    Системные файлы: [Ставить…]
    при форматировании выдаётся сообщение:
    Системные файлы: Не ставить
  • Неудача при запуске первого американского спутника к Венере случилась, вероятнее всего, из-за ошибки в программе – вместо требуемой в операторе точки программист поставил запятую. Вот как был записан этот оператор:
    DO 50 I = 12,525
    На самом же деле он должен был выглядеть следующим образом:
    DO 50 I = 12.525
  • Потеря связи с космической станцией «Фобос-1» (СССР) произошла из-за ошибочной команды, переданной с Земли на бортовой компьютер.
  • Причиной осложнений, возникших при возвращении на Землю советско-афганского и советско-французского экипажей, явились ошибки, допущенные в программном обеспечении бортовых компьютеров.


Тип 2. Ошибки, возникающие при вводе в компьютер неверных данных

  • В 1983 году произошло наводнение в юго-западной части США. Причина заключалась в том, что в компьютер были введены неверные данные о погоде, в результате чего он дал ошибочный сигнал шлюзам, перекрывающим реку Колорадо.


Тип 3. Компьютерные вирусы, «вмешивающиеся» в работу компьютера и выполняемую им программу

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


Тип 4. Выход из строя элементов компьютера и обслуживающих его систем

  • В процессе эксплуатации компьютера возможно физическое повреждение накопителя на жёстком магнитном диске, выход из строя блока питания, отключение электроэнергии, колебания напряжения в электрической сети и др. Результатом такого рода неисправностей может быть полная потеря информации, хранящейся на жёстком магнитном диске, частичная или полная потеря информации в файлах баз данных, нарушение работы систем, управляемых компьютером и многое другое. Для предотвращения ошибок данного типа используют системы, в которых одновременно работают несколько компьютеров, дублирующих друг друга, в компьютеры устанавливают два параллельно работающие накопители на жёстких магнитных дисках, компьютеры подключают к источникам бесперебойного питания, которые обеспечивают его работу при отключении электроэнергии или колебаниях напряжения электрической сети и др.


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

  • В июле 1985 года произошло преждевременное отключение компьютера одного из основных двигателей американского космического корабля «Челленджер» (Шаттл), едва не закончившееся катастрофой. Положение спас командир корабля, сумевший на двух работающих основных двигателях и двух менее мощных двигателях для маневрирования вывести «Челленджер» на орбиту. Причина же заключалась в том, что один из трёх бортовых компьютеров, управляющих двигателями (на каждый двигатель по компьютеру), был «обманут» вышедшим из строя датчиком, измеряющим температуру газа в двигателе. Для устранения подобных неполадок в будущем на следующих космических кораблях серии Шаттл были установлены датчики изменённой конструкции.
  • При запуске французской ракеты нового поколения «Ариан-5» примерно на 37-й секунде полёта компьютер, находившийся на борту ракеты, получил от датчиков системы управления неверную информацию о пространственной ориентации ракеты. Исходя из этой информации, компьютер начал корректировать траекторию полёта для того, чтобы компенсировать не существующую на самом деле погрешность. Ракета стала отклоняться от курса, что привело к возрастанию нагрузок на её корпус. В результате чрезмерных нагрузок верхняя часть ракеты отвалилась, и по команде с земли ракета была взорвана.


Тип 6. «Злая воля человека», носителем которой чаще всего выступает либо программист, либо оператор

Программист, создавая программный комплекс, может специально внести в него ошибку. Другим вариантом проявления «злой воли программиста» является включение в программу «логической бомбы», срабатывающей, например, после определённого числа запусков программы, определённых значениях входных данных и др. Оператор, обслуживающий компьютер, может сознательно ввести в компьютер неверные данные, которые и будут обработаны компьютером, выдавая неверные выходные данные в соответствии с принципом «мусор на входе – мусор на выходе»
  • • Сборочный конвейер волжского автомобильного завода в городе Тольятти работает под управлением ЭВМ, которая обеспечивает своевременное поступление деталей на конвейер со складов и из цехов вспомогательных производств. Для выполнения этой задачи информационно-управляющая система хранит информацию о тысячах узлов и деталей, из которых собирается автомобиль, о запасах деталей на складах, об их движении по транспортным линиям и т. д. На основе этой информации ЭВМ самостоятельно управляет автоматизированными складами, транспортными конвейерами, а также рядом других устройств.
    Программист, разрабатывавший программное обеспечение для управления главным конвейером Волжского автозавода, сознательно внёс в программу «логическую бомбу» в знак протеста против низкой зарплаты. Через некоторое время эта «логическая бомба» сработала, и главный конвейер остановился на несколько дней. Ущерб от остановки составил 1 миллион рублей (в ценах 80-х годов), этот ущерб был несопоставим с зарплатой всех программистов ВАЗа, вместе взятых, а программист был дисквалифицирован и переведён в рабочие.


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


Таким образом, программный комплекс в обязательном порядке должен проходить тщательное тестирование и отладку (выявление ошибок 1-го и 2-го типов). Выявление возможных ошибок 5-го типа производится с помощью имитации отказа приборов и датчиков на прошедших тестирование программных комплексах.

Поиск ошибок — увлекательное и полезное занятие, но требующее огромных затрат сил и времени, так что легче не допустить ошибку, чем допустить и потом её искать :) К тому же, на дворе кризис, значит программисты просто обязаны делать меньше ошибок :)))

Надеюсь, моя подборка поможет новичкам и не только им. Удачи вам и поменьше ошибок в ваших творениях

Отключаем проверку совместимости дополнений в Firefox

Каждый пользователь Mozilla Firefox рано или поздно обзаводится набором необходимых дополнений, но стоит выйти новой версии браузера, как большинство из них становится недоступными. Многие решают проблему путем ручного вписывания нового релиза в список поддерживаемых для каждого плагина, однако это далеко не самый удобный способ, особенно, если у вас таких дополнений штук 10-20.

Самый простой способ — отключить проверку совместимости, встроенную в сам браузер. Делается это просто:

1. Заходим по адресу about:config
2. Создаем новый ключ (меню вызывается правой кнопкой мыши) под названием extensions.checkCompatibility и задаем ему значение false.

Несколько способов улучшить пользовательский веб-интерфейс на примерах

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

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

Создание веб студии с «0»: часть 1

Сегодня я рассмотрю возможность и перспективы создания достаточно профессиональной (другая ведь и не нужна) веб студии с «0» своими руками (и головой).
Всё, что здесь будет написано, основано на собственном опыте, мыслях и некоторых советах профессионалов в проектном менеджменте.
Итак, начнём.
Читать дальше →

Упорядочивание дизайнерских материалов — взгляд изнутри.

Добрый день,

Под впечатлением прочитанной статьи я решил написать статью-ответ как альтернативный вариант упорядочивания материалов.

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

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


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

    Примечание: фигурные скобки в именах каталогов используются для того чтобы они отображались первыми при сортировке — это довольно удобно.

    #Основная структура:

    D:\{work}\ # вся работа тут :)
    D:\{work}\{archive}\ # архив за прошлые годы
    D:\{work}\{archive}\2008\ # архив работы за 2008 год
    D:\{work}\clientID\ # ID клиента
    D:\{work}\clientID\projectID\ # ID проекта
    ...

    # Структура внутри проекта (D:\{work}\clientID\projectID):

    \taskID\ # ID задачи, например: "web.design"
    \taskID\docs\ # контакты, письма, примеры, переписка и т.п.
    \taskID\done\ # финальная версия
    \taskID\inproc\ # то, что сейчас в работе по данной задаче
    \taskID\inproc\demo\ # поточные демонстрашки
    \taskID\sources\ # исходные материалы (картинки, макеты и т.п.)

    # Вид файлов каталога \taskID\done\ :

    task-sub-20090630-pscs3-cmyk-2480x1200.tif # без слоев!
    task-sub-20090630-ilcs3-cmyk.eps # в кривых!
    ...

    # Вид файлов каталога \taskID\inproc\ :

    sub-01a-en.psd # например, homePage-01a-en.psd

    # Вид файлов каталога \taskID\inproc\demo\ (как и макеты, только JPEG):

    sub-01a-en.jpg # например, homePage-01a-en.jpg

    # Каталог исходников: \taskID\sources\ :
    # Тут может быть что угодно, что относится к делу, например: клипарт,
    # логотип(ы), другие макеты с нужными детальками и т.п.

    \taskID\sources\clipart\*.jpg # клипарт
    \taskID\sources\fromInet\*.jpg # нарыто из сети
    \taskID\sources\logo\*.eps|psd... # имеющийся логотип
    \taskID\sources\oldvars\*.psd|eps # старые варианты на запчасти



    Теперь немного разъяснений:

    В архив попадают клиенты/проекты/работы по мере их закрытия + 2-3 месяца на «отстой», если вдруг клиент «проснется» и захочет что-то быстро (до/пере)делать.
    Т. обр. проекты одного клиента могут частично быть уже в архиве.
    Или же задачи проекта могут частично перейти в архив из-за неактуальности.

    Это дает возможность содержать структуру проектов с небольшим количеством каталогов текущих проектов и не путаться в них, а так же не использовать скучную прокрутку в поисках того что в данный момент надо делать :-)

    Теперь давайте проанализируем как происходит рабочий процесс с использованием предложенной структуры:

    Я прихожу на работу и открываю папку \{work}

    Звонит (или пишет) клиент — я узнавая его захожу в его каталог \{work}\clientID

    По первым его фразам становится ясно по какому проекту он меня тревожит, я уже захожу в нужный проект: \{work}\clientID\projectID

    Далее, становится ясно о какой задаче (или виде работ) идет речь (это может быть дизайн, верстка или прогарммирование), я захожу в нужную задачу:
    \{work}\clientID\projectID\taskID\

    в реальности это выглядит примерно так:

    \{work}\Opel\opel.com\web.design\

    ну и там по ситуации — если идет речь о какой-то демке, которая была выслана ранее, я открываю демку, прослеживаю ход мысли клиента, захожу в \inprocess\ открываю нужный макет, вношу требуемые изменения и дальше 2 варианта:

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

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

    Было бы интересно, как другие специалисты IT-сферы решают подобные вопросы систематизации. Я почти уверен что есть способы улучшить мою схему.

    Буду благодарен за приглашение на хабр, — смогу периодически писать статьи аналогичные данной, делиться практическим опытом и своими мыслями.

    Спасибо,
    Максим

ASP.NET MVC Framework – убираем точки!

Данная статья является единственным доступным для меня способом реакции на опус "ASP.NET MVC Framework – ставим точки". Не имея аккаунта на хабре а значит и возможности ответить автору, хотелось хотя бы в песочнице излить душу. Что же не так в вышеупомянутом опусе? А то, что читая его и коментарии к нему понимаешь, что люди в основной своей массе не до конца разобрались, что же за зверь такой — ASP.NET MVC. Но уже собирают крестовый поход в защиту старого доброго классического ASP.NET. Еще раз повторю, что не хочу обидеть автора оригинальной статьи, а просто высказываю свое (естественно субъективное) мнение.

Но для начала некоторые факты


Ни для кого не секрет, что множество веб-фреймворков делится на подмножества компонентно-ориентированных (component based) и запросо-ориентированных (request-based). Не вдаваясь в детали, приведу несколько фактов фактов чтобы почувствовать разницу:
  • request-based — все крутится вокруг запроса, при этом получаем чистый html, четкое разграничение ответственности, но есть проблемы с повторным использованием и сохранением состояния.
  • component-based — здесь строится абстракция поверх стандартного для веб конвейера обработки запроса, при разработке интерфейса пользователь оперирует компонентами, состояние сохраняется автоматически (зловещий ViewState).

При всей кажущейся привлекательности request-based модели, со всей ее академической чистотой и легкой тестируемостью, модель component-based также имеет право на существование. Почему? Во первых, потому что она решает главную проблему stateless протокола http — сохранение состояния. (Попробуйте, например написать wizard на MVC фреймворке и поймете чего стоит отсутствие состояния). Во вторых, хорошо построенная абстракция компонентов позволяет решить проблему повторного использования элементов интерфейса и очень хорошо ложится на ajax.

Теперь к нашим баранам


Кто еще не понял ASP.MVC — это request-based, а классический ASP.NET — component-based. То есть это две совершенно разный парадигмы, сравнивать их также некорректно как сравнивать корову с апельсином. Каждая парадигма имеет свои плюсы. Но у классического ASP.NET есть один ну оочень зерьезный минус — тотальная порочность архитектуры. Во времена его написания программсты Microsoft не знали (или не хотели знать), о надобности тестируемости, интерфейсах, IoC, dependency injection и многом многом другом. Бесконечные синглтоны, статические методы и жесткая зависимость от конвейера обработки запроса лишили шансов покрыть тестами хоть что-то. А адаптеры данных, размещаемые прямо на странице и вовсе убили само понятие
«архитектуры». Команда, которая разрабатывала ASP.MVC, напротив, подошла к вопросу грамотно, реализовав отлично тестируемую и гибкую архитектуру. Да еще и дополнив ее обертками над стандартными аэспешнами синглтонами (HttpContext, Request и тд).

Теперь собственно к статье


Сначала автор говорит нам когда не нужно использовать ASP.NET MVC
* вам не нужен MVC Framework, если вы считаете, что он лучше классического ASP.NET. Если вы так думаете, значит вы плохо знаете ASP.NET, вам есть еще куда расти и что изучать. Если вы думаете, что MVC Framework лучше ASP.NET, значит вы не полюбили ASP.NET и не поняли всей прелести его идеологии. В таком случае вам рано переходить на MVC Framework. Переходить на новый фреймворк просто неоткуда, если у вас нет должного понимания и любви к базовому механизму. Изучить ASP.NET, поймите почему и как там все устроено. MVC Framework вам не нужен;

Первая неувязка в этом абзаце — как можно сказать что ЛУЧШЕ если это совершенно разные парадигмы? Зачем мне любить ASP.NET чтобы перейти на MVC? Это тоже самое что стараться выучить китайский, изучая химию.

Идем дальше


* вам не нужен MVC Framework для того, чтобы использовать паттерн MVC.

А для чего же он, пардон, тогда нужен?
В самом деле MVC не имеет никакого отношения к конкретной библиотеке. MVC Framework — это всего лишь реализация паттерна, которую никто не мешает вам создать и использовать самому в классическом ASP.NET. Попробуйте, это не трудно. MVC Framework вам не нужен, если причина только в том, что он MVC;

Да, MVC — это всего лишь паттерн. Паттерн, которай неплохо реализован для .NET в виде библиотеки ASP.NET MVC. Почему автор призывает не использовать готовое решение, а изобретать велосипед? Сложно сказать, но это, конечно, бред. Если вы хотите использовать паттерн MVC, НИ ЗА ЧТО НЕ ПИШИТЕ его сами! Используйте ASP.NET MVC! Лучше программистов Microsoft вы его все равно не напишите!

Далее перемещаем внимание в раздел «Почему вам нужен MVC»

Среди прочего читаем:
* и основная и главная причина, по которой вам нужен MVC Framework — это абсолютная расширяемость. В этом плане MVC Framework — это действительно каркас, который может быть заполнен так, как нужно вам. Можно провести следующее сравнение: классический ASP.NET — это картина, нарисованная мастером, тогда как MVC Framework — это набросок, эскиз, который зарисовать, доделать предоставляют вам самому. В MVC Framework вы способны переопределить действие механизма на любом этапе от обработки
запроса, до отправки результата.

Я, честно говоря, не совсем понимаю метафору автора с картинами (а уж то, классический ASP.NET — шедевр написанный мастером меня просто убило). В свою очередь хочу заметить, что расширяемость является неотъемлемой частью ЛЮБОЙ хорошо спроектированной программной системы. Так что здесь уместнее говорить о НЕрасширяемости стандартной модели ASP.NET, ее зажатости и антипаттерной
архитектуре.
Переход на MVC Framework не должен стать для вас поиском избавления от «проблем». Посмотрите на проблемы пристальнее и вы увидите, что все они решаются в рамках классической модели ASP.NET.

Да, хорошо можно писать на чем угодно, хоть на Алголе. Можно и классическом ASP.NET решить все проблемы. Но зачем? Только ради того, чтобы это была стандартная модель?
Сила MVC Framework в его возможностях и потенциале к расширяемости. MVC Framework — это тот конструктор, который вы должны пожелать после того, как полностью насытились проверенными инструментами.

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

Ошибкой родителей было зачать создателей классического ASP.NET, а желание избавится от недостатков и применить паттерн — это всегда благое дело!

Итак, подведу итог.


Были времена, когда Microsoft в своей работе над программными продуктами видели цель в создании инструментов rapid develpment. То есть быстрой (читай корявой) разработки. Ацким детещем той эпохи явился монстр ASP.NET. Сейчас времена изменились, и MS вовсю пропагандирует академически чистый подход, применение паттернов и юнит тестирования. В связи с этим надеюсь, что морально устаревшая модель классического ASP.NET в скором времени отойдет в мир иной и освободить дорогу свежим решениям!

PS. Прошу прощения за возможные ошибки и эмоциональный стиль — писАлось второпях, на одном дыхании.

Совсем семантическая…

В этой статье речь пойдёт о HTML+CSS.


Для многих давно стала очевидной необходимость отделения представления от данных. Как в настольных приложениях бизнес-логика отделяется от пользовательского интерфейса, за счет чего достигается гибкость и рефакторинг кода, так и в вебприложениях следует разделить выполнение запросов к БД и внешним сервисам (в случае с Веб 2.0), бизнес-логику, и сборку HTML для клиента.

К сожалению, популярные CMS Wordpress, Joomla, Drupal, а также Bitrix собирают html-ответ средствами динамического программирования (и include), что противоречит не только здравому рассудку, и, в частности, парадигме ООП.


Читать дальше →

Решаем практические задачи на батниках

Большинство айтишников, которые работают под Windows, используют не все возможности батников, либо используют PowerShell, Python или подобные более мощные вещи. Да, конечно, батники это не мощный язык программирования и некоторые задачи на нем решить не возможно, но, в то же время, это инструмент, который всегда под рукой и на нем можно решить много рутинных задач.



Цель статьи не просто рассказать о возможностях Windows-консоли, а показать их, решая практические задачи с которыми мне приходилось сталкиваться.


Читать дальше →

Пара слов о «форумчанах» (кратко)

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

Для начала определим, что такое — тематический форум? Тематическим форумом можно назвать сообщество людей, объединенных общими интересами и встречающихся для обсуждения «интересов» в сети посредством программных продуктов (php, sql и т.д.). Сейчас каждый человек, который так или иначе связан с IT или «около IT» сферой имеет в своем браузере более двух-трех закладок на свои «любимые» форумы, где он может посидеть с чашкой чая за лэптопом и обсудить мировой кризис или же наоборот, поругаться с кем-либо, кого не устраивает его точка зрения.

Существуют 3 причины постоянного посещения форумов:
1. Обмен информацией;
2. Знакомство с новыми людьми;
3. Изменение психологического состояния (снятие стресса, например);

Т.к. я пишу кратко о своем исследовании, я опущу обоснование первых двух причин и обращусь сразу к последней — к психологическому состоянию человека в момент посещения «своего любимого форума».
Однажды меня заинтересовало одно направление в кино-индустрии и я решил поискать в своем городе людей, с которыми бы я мог пообщаться на эту тему. Облазив различные подфорумы форумов, сайты клубов, я понял, что нет в нашем городе одного глобального форума по данной тематике. И создателем такого форума стал я. Взяв за основу бесплатный phpbb и зарегистрировав доменное имя, я разместился на одном питерском хостинге. Спасибо поисковым
машинам за индексацию, т.к. уже через неделю я имел на своем форуме он-лайн в 25 человек (заметьте, я не пользовался рекламой) и более 100 зарегистрированных пользователей.

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

п.с.: прошу прощенья за краткость до нельзя. Если я получу инвайт, я выложу свое полное исследование, если оно, конечно, кому интересно.

Спасибо за внимание.

Как заставить пользователей искать ошибки ввода

В нашей фирме идет большой поток заказов оформленных в не цифровом виде — факсы, почта.
В ходе ввода данных в программу бывают ошибки ввода. Ошибка ввода это в худшем случае не дошедший заказ и недовольный клиент, потерянная реальная и потенциальная прибыль. Это очень плохо.
Обычно такие проблемы решаются просто — либо технически продвинутая система проверки данных и подсказок, либо организационно (депремированием на сумму заказа)
В нашем случае оба варианта не сработали.
Причем организационный вариант дал интересный результат. Ошибки стали возникать по графику. После ошибки сотрудник 2 дня проверял форму по два раза. на 3 день один раз, а потом скатывался на автоматизм и через неделю снова делал ошибку. Конечно у каждого сотрудника свой период, но график примерно одинаковый для всех.

Была поставлена задача: убедится что сотрудник действительно проверяет данные перед отправкой заказа

Сделали так:
После заполнения формы, сотруднику показывается новое окно с данными для проверки. Но не простые а измененные. Хитрость в том, что программа иногда в произвольном порядке вносит в данные ошибки свойственные людям(задвоенные символы, перестановка символов, меняет о на а, и на е и т.д.). Если нерадивый сотрудник не подметивший подвох пытается подтвердить внесенные данные, программа сообщает ему ( и руководству) о том что он пропустил ряд ошибок. Приходится чательней проверять и исправлять.
Причем программа отслеживает изменения только в измененной ей данных. Если сотрудник исправит и реальную ошибку ввода, программа ругаться не будет.

Опыт применения показал три важные вещи
  • Ошибок стало намного меньше. Но они до сих пор есть.
  • Производительность снизилась заметно. Поскольку теперь проверяют и проверяют хорошо. А это требует времени
  • Сотрудники стали сильнее уставать. Постоянные проверки выматывают

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

Быстрое развёртывание сборочной среды для Qt4 приложений под Visual Studio 2008

Все привыкли, что для того, чтобы собрать что-то кутишное с использованием Visual Studio 2008 — это вечный гемморой с ручной сборкой Qt, доставлением всяких zlib'ов, ковыряние в путях и тд… То есть это примерно целый день ковыряний.
Но есть способ как это всё сделать минут за 20-30, для этого понадобится кдешный инсталятор для винды, который помимо всего прочего представляет из себя вполне традиционный для юниксов менеджер пакетов.
Читать дальше →

Еще про индексирование деревьев в реляционной БД

Посмотрел неплохую презентацию про работу с деревьями в БД, недавно пробегавшую на Хабре.

В дополнение к ней предлагаю посмотреть слайды с моего выступления на SEF-2009. Как раз по этой теме — "Построение индекса по иерархии записей в реляционной БД". Кроме обычных подходов, там еще дается подробное описание метода, который мы придумали для себя.

TinyMCE и Geshi

При написании своего движка столкнулся с проблемой, как прикрутить подсветку кода Geshi к TinyMCE, так или иначе перебирал различные комбинации:

{code lan=php}{/code}
[code lan=php][/code]


Но в результате визуализация Tiny съедала всё это, делала автоматическую чистку тэгов, конечно есть опция:
tinyMCE.init({
...
verify_html : false
});


Но она также не подходила мне, т.к. вызывала кучу других проблем. в итоге пришёл к опции:
Читать дальше →