Далеко-далеко, где-то на краю Галактики, я обнаружил весьма впечатляющее NoSQL решение…

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

Маркетинговая затравка от авторов звучит примерно так:

BaseX является очень легковесной, высокопроизводительной и масштабируемой XML базой данных с XPath/XQuery 3.0 процессором, который имеет полную поддержку W3C Update и Full Text спецификаций. Интерактивный и дружественный графический интерфейс позволяет легко изучать ваши XML документы

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

Часть 1

В данной статье мы рассмотрим базовые понятия событийной модели StateController'а.

Зоны распространения событий

В селективной модели приложений работа ведется с теми элементами, которые были предварительно выбраны для работы. В чистой событийной модели событие должно распространяться на все элементы DOM-дерева. Это совершенно не важно на маленьких объемах, но при росте количества нод деградация скорости будет даже не линейной. Представьте себе, что событие click должно пройтись по всем нодам, чтобы определить, на каких именно элементах оно сработает. Есть предположение, что псевдокласс :hover в IE6 именно так и работал, поэтому он так сильно тормозил.

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

Введение

Сейчас все больше и больше появляется JavaScript-фреймворков, которые несколько отличаются от нынче модного jQuery. Одни стараются реализовать MVC, другие предоставляют сильносвязанную архитектуру, третьи направлены на асинхронность, и так далее. Каждый разработчик выбирает то, что ему ближе всего, и что наиболее эффективно решает поставленную задачу. Поэтому я не буду обсуждать достоинства или недостатки фреймворков, а расскажу, к чему пришли мы в наших продуктах, какие концепции разрабатывались и какие проблемы решались.

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

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

Что нам дает знание «языка», на котором общается работник с менеджером или менеджер с руководителем? Как это применять на практике? Кому это нужно?

Начнем, пожалуй, с последнего вопроса.

Кому это нужно?

Всем.

Работники хотят показывать начальству свою эффективность, чтобы лучше монетизировать свой труд. Они хотят спокойно трудиться, без авралов, без показательных раздач оплеух, в здоровой атмосфере. Такая себе творческая рабочая нирвана.

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

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

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

Я часто слышу фразы, что «начальник урод», «ПМ *** и требует от нас невозможного», «мы боремся с адовым количеством проблем из-за того, что руководство стелется под заказчика», «нас сделали виноватыми и оштрафовали ни за что» и так далее. Разработчики возмущены действиями и решениями своих менеджеров (или же их отсутствием), управленцы проводят карательные операции по отношению к «тунеядцам» и «раздолбаям», топ-менеджмент проводит рейды вазилинирования всех подряд, чтобы процесс зарабатывания денег не прекращался.

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

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

Подбору «железной» части и посвящена данная статья.

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



Любой проект начинается с технического задания. Так было раньше, а для многих это остается аксиомой до сих пор. Это не плохо, однако мы практически полностью отказались от ТЗ. Теперь это сокращает нам огромное количество времени, которое тратилось раннее практически впустую.

Рабочая группа CSS3 постоянно ведет дискуссии по поводу того, что же будет в новом стандарте. Иногда буйная фантазия и желание сделать все настолько круто, насколько это возможно, приводит разработчиков в глухой тупик.

Предыдущая часть тут

Анимация скрытых объектов

Похоже, одной из серьезных проблем для модуля CSS3 Animations станут объекты, которые имеют display: none и visibility: hidden.

Рабочая группа CSS3 постоянно ведет дискуссии по поводу того, что же будет в новом стандарте. Никаких скандалов, интриг и расследований. Голые мысли, непрекрытые идеи, обнаженные факты.

Предыдущая часть тут

Немного магии в линейных градиентах

Предложен новый способ рисования линейных градиентов. Как известно, такие заливки рисуются по линии градиента (gradient-line), отправной точкой которого является центр контейнера. Однако, если захочется нарисовать градиент похитрее, без дополнительных костылей в виде JS не обойтись. Например, есть градиент с тремя цветами: А, Б, В. Захотелось заполнить контейнер так, чтобы цвет А был «привязан» к левому верхнему углу, цвет Б — к правому верхнему, а цвет В — к правому нижнему. И при изменении размеров контейнера результат всегда был одинаковым.

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

Рабочая группа CSS3 постоянно ведет дискуссии по поводу того, что же будет в новом стандарте. Чтобы держать руку на пульсе, я постараюсь еженедельно выкладывать самые интересные моменты из их обсуждения.

Регионы

Начнем с того, что выложили новый черновик (draft) модуля CSS3-Regions. Этот модуль создавался для более точного управления потоком, облегчая создание таких дизайнов как этот:


Стоит отметить, что авторами данного модуля являются господа из Adobe Systems, Inc, и подобное поведение (перетекание текста из одного региона в другой) хорошо известно пользователям таких продуктов как Adobe Illustrator, Adobe InDesign, и даже Corel Draw.

«Регионы» могут стать главным инструментом верстальщика, так как позволяет создавать удивительные обтекания по заданной траектории.

Тестирование скорости выполнения JS или отображения страниц — занятие неблагодарное. Любое тестирование отражает действительность только тогда, когда оно выполнено в как можно более одинаковых условиях и тестируются идентичные по функциональности вещи. Ведь на вопрос, что быстрее, грузовик или спорткар, каждый тут же ответит, что спорткар. А если по полю да с прицепом навоза? Победитель в каждом случае будет тот, кто лучше всего приспособлен для выполнения специфических задач.

В этой статье будет немного гипотез и немного фактов. Не будет фанатских речей и призывов сменить браузерную ориентацию.

Итак, наши подопытные кролики:

• FF 4b7
• Opera 10.63
• Chrome 7

Я не тестировал IE9, потому что у меня он установлен на виртуальной машине, а это чревато наличием пенальти по скорости и ощутимым разбросом значений.

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

Сказка про то, как мы биллинг проектировали

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

Вы руководитель компании по производству ПО, директор веб-студии или фрилансер, который хочет вылететь в трубу через пару лет ведения бизнеса? Тогда статья для вас! Я научу вас нескольким ужасным ошибкам, которые позволят медленно и мучительно долго просадить ваше состояние.

Демпинговать, демпинговать и еще раз демпинговать

Сферический заказчик в вакууме хочет разработать некий программный продукт. Вы, компания «А», решили поучаствовать в тендере на его разработку. По вашим оценкам он должен стоить 100 килотугриков. Компания «Б» оценила проект в 50 килотугриков, а компания «В» не поняла техническое задание и оценила проект в 5 килотугриков. Вы просто обязаны демпинговать, и установить цену в 2.5 килотугрика. Вы должны всех перехитрить. Этот проект ведь очень важен для вас, вы и только вы можете его сделать. Пусть конкурент обзавидуется уровню вашего мастерства демпингования!

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

Маленькие проекты позволяют получить высокую доходность при низкой себестоимости. Масштабирование доходов решается путем привлечения новых работников. Форс-мажоры не особо влияют на благосостояние компании. Самое главное, что это быстрые деньги. Звучит очень привлекательно!

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

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

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

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

Моя предыдущая статья «Чего я ждал от HTML5 и CSS3» затронула достаточно щекотливую тему, но не ответила на вполне резонный вопрос, а что я предлагаю взамен. Поэтому мне в голову пришла идея сделать общественную спецификацию CSS, которая будет отражать современные тенденции развития web-технологий и требования к будущему функционалу. Я приглашаю всех поучаствовать в разработке нашей собственной версии спецификации. Если популярность ее будет достаточно высокой, ее могут принять все разработчики браузеров, а от этого выиграют и web-разработчики, и пользователи.

Первый механизм, который я представляю вашему вниманию называется «направляющие»

Любителям «священных войн» вход строго воспрещен!

Для многих людей FAR оставался и остается одной из самых любимых программ. Достоинств у нее много, недостатков тоже. Но этот топик не про это. Многие хотят продолжать использовать FAR и дальше, но уже под Linux'ом.

Что нам нужно?

• Ubuntu Lucid Lynx 10.04
• FAR manager 2.0 (я обычно качаю 7zip архив, и далее речь пойдет именно про него)
• Wine 1.2

Поехали? (Осторожно, много картинок)

Многие менеджеры сталкиваются с одной очень занимательной проблемой в IT-сфере. И имя этой проблеме — оценка эффективности работника. Еще пол столетия назад такая задача не вызывала приступов мигрени и паники у руководителей или экономистов, потому что все было просто. Работник закрутил 50 гаек — плохо, закрутил 150 гаек — великолепно! Но пришла революция информационных технологий, и оценка эффективности стала краеугольным камнем.



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

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

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

Веб разработкой я занимаюсь давно, и помню еще IE3 и NN4.xx. Многое изменилось с тех пор, много воды утекло. Пришло понимание всех технологий не на уровне «HTML — это текстовый файлик, в котором попадаются какие-то слова в скобочках», а понимание логики построения самого языка разметки, его абстракций.

Начало разработки спецификаций HTML5 и CSS3 уже не вызывала у меня щенячьего восторга и бурной радости, а воспринималась как вполне эволюционное событие. Заглядывал я в рабочие черновики изредка, отмечая для себя основные направления развития. Но чем больше спецификации приближаются к финалу, тем страшнее мне становится. Это не то направление развития, которое требует рынок!

Возникает резонный вопрос, куда делись все те люди, которые разрабатывали стандарты 10 лет назад? Куда делись инновации? Почему w3c создает стандарт, который, по некоторым меркам, уже устарел?

Давайте разберемся.