Библиотека Интернет Индустрии I2R.ru

Приветствую вас, дорогие читатели нашей рассылки! Для начала хочу объявить о нескольких интересных конференциях для веб-разработчиков, которые пройдут этой весной. В апреле месяце состоится первая в России масштабная конференция «Российские Интернет Технологии 2007» (РИТ 2007); инициатор мероприятия - Олег Бунин. Основные задачи конференции это: "формирование отрасли веб-разработок в России, ее стандартов, профсоюзов, обсуждение приоритетных направлений развития. Необходимость в проведении всероссийской встречи разработчиков назрела давно. Ведь, по сути, у нас нет ни одного издания и ни открытого мероприятия, где бы мы, разработчики интернет-приложений, могли бы собраться и просто поговорить" - пишут на сайте конференции организаторы. А со списком приглашённых на конференцию гуру можно ознакомиться уже сегодня.

Вторая, не менее интересная веб-разрабочикам конференция PHPCONF 2007 пройдёт в мае месяце в Москве. Формат PHPCONF 2007 включает 2-х дневную конференцию и серию мастер-классов, которые будут проходить в течении недели перед началом мероприятия. В программе - Эффективное применение PHP в веб-разработке, эффективное создание веб-приложений, PHP и корпоративные информационные системы и, конечно же - будущее PHP. Организаторы конференции приглашают докладчиков, профессиональных веб-разработчиков, которые готовы поделиться своим опытом по теме PHP.

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

В копилку речь одного руководителя:

По большому счёту мне не особенно важно, чтобы вы были в офисе к 9 утра - приходите хоть к часу дня (временная разница с ним - семь часов, и для синхронизации работы лучше бы приходить в три и уходить в час ночи). Мне не особенно важно, сколько часов вы работаете, отрабатываете положенные 8, или 4-6, или 10-12 - мне главное, чтобы была выполнена объявленная работа.
У нас бывают авралы, когда работать приходится много больше, и есть лёгкие дни, когда работы практически нет. В среднем оно то на то и приходится - нагрузка уравнивается. Если же по какой-то причине разработчику приходится сидеть больше 8 часов над работой - к примеру, в силу его непроходимой тупости или ошибок - пусть сидит и переделывает сам в счёт своего времени.

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

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

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

Навеяно разборкой и модификацией кода "программистов"-студентов, которых наше начальство постоянно где-то находит взамен ушедшим кодерам. Очень грубо и однобоко. Но просто наболело.
1. Новичок. Из постановки задачи выбираются знакомые слова, между которыми новичок интуитивно пытается найти какую-либо связь (ну хоть какую-то). При реализации в ход идут все средства. Зачастую используется чужой код, который каким-то магическим образом делает "что-то похожее". Основная цель - получить результат. Не важно как. Иногда ожидаемый результат получают на промежуточном этапе реализации, на чем и останавливаются обрадованные. Это не халтура, это целенаправленное зло, вред всему проекту. Хуже вируса.
2. Кодер. Постановка задачи понимается "как есть", без обсуждений и конкретизации отдельных моментов. Реализация очень похожа на дословный перевод текста с иностранного языка. Кодер при реализации некоторого модуля совершенно не задумывается о уже существующих связях между соседними модулями так же как и о роли и месте разрабатываемого модуля в рамках всего проекта. При необходимости кодер модифицирует соседние модули в соответствии со своими нуждами. Это халтура.
3. Программист. Конечного этапа развития программиста нет, поэтому будет рассматриваться некая виртуальная степень профессионализма, близкая к потолку. Программист - это всегда еще и постановщик. Он никогда не возьмется за реализацию пока не поймет что конкретно от него хотят и как результат должен взаимодействовать с остальным кодом проекта. Принемаясь за реализацию, программист будет более-менее четко (в некоторых случаях дословный код будет стоять перед глазами и ждать того, что его вколотят) представлять себе структуру и наполнение своего модуля. В этом заключается основная особенность программиста: сначала думаем и только потом делаем. Программист всегда будет пытаться обобщать, оптимизировать свой код... Главное - программист, работающий в команде не станет останавливаться на дословном исполнении своего куска ТЗ (типа как сказали, так и сделал. А остальное нии...не волнует), т.е. реализует его не в рамках локальной задачи, а в рамках всего проекта (обсудив с основным постановщиком естессно). Он подготовит свой модуль к использованию так, чтобы остальным учасникам проекта не пришлось шлифовать углы и расширять функциональность этого модуля под свои нужды. Основная особенность программиста - он может реализовать практически всё пятью различными способами. И вместо поиска путей реализации он имеет возможность сконцентрироваться на выборе наиболее оптимального и уместного в рамках реализуемой задачи.

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

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

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

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

В одном из прошлогодних декабрьских постов я рассказывала о том, что в конце года мы заполняли некое "review" для наших заокеанских работодателей, где можно было в специально отведённых полях описать всяческие пожелания/рекомендации по усовершенствованию работы фирмы (на будущий год). Там я и написала, что нашей фирме "Need Analitic Manager (qualified, hightskill)", и на войсовом собеседовании с руководством (оно, в общем и целом, было просто голосовым обсуждением отосланного по мейлу review) наш руководитель долго пытал меня - что я, собственно, имею ввиду и зачем нам, собственно, такой специалист. И вот что удивительно. По окончании собеседования он меня практически убедил в том, что аналитик - это какой-то бесполезный атавизм, бессмысленный пожиратель денег и времени, и вся работа без специально заточенного аналитика выполняется превосходно.

А теперь я поняла в чём дело! Я же по-просту оскорбила нашего руководителя - он-то считал, что всю работу аналитика он выполняет, и причём успешно... Ну что же это я так... ещё бы уволиться ему предложила. Нехорошо.

Т.е. руководитель направления (вот как раз представленный выше "аналитик") объявляет тему разработки, описывает приблизительно - что он видит на выходе. Последующий же анализ (техническая сторона проекта) ложиться на разработчика - всё, что касается выбора платформы, инструментов разработки, проектирования системы (баз данных, модульной структуры, прочего, прочего). И по его логике выходит, что *кодеров* в нашей конторе быть не должно и близко - каждый первый обязан просто быть системным программистом, владеющим системным анализом, и при этом ещё и более чем образованным человеком - ибо разбираться придётся с таким количеством прикладных задач, от бухгалтерии и систем оплат до... бесконечности, в общем, потому как кухня может быть любой, и программисту даётся символически мало времени на то, чтобы въехать в тему.

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

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

На самом деле в любом проекте допустим некоторый процент костылей и подпорок, но такая система будет работать только в том случае, если руководство не провоцирует текучку кадров, серьёзно же расчитывать на помощь в проектировании со стороны конечных разработчиков, так же как и на бесконечное докостыливание в фоновом режиме - не солидно как-то. А так обычно получается, как в одном из законов Мерфи: "В каждой организации есть человек, который знает, что на самом деле происходит. Его-то и надо уволить".
У нас как бы не увольняют, но создают атмосферу-условия, когда разработчик, на текущий момент самый грамотный и соображающий (и пытающийся всё-таки проявлять инициативу, участвовать в проектировании) уходит сам. В итоге: еправильная постановка (причём не в техническом смысле, а в искажённом описании задачи - когда задачи не тривиальные и общего образования программистам не достаточно для того, чтобы понять тему), а потом - это программисты виноваты, плохо сделали: под этим прессингом любые, самые талантливые разбегутся. Особенно при условии, что талантливые как раз видят слабые места, и видели в процессе, и - более того - озвучивали неоднократно, за что были осуждаемы тем же ответственным начальником - мол, сроки затягивают, скорости реакции сделать "по-быстрому" не хватает, лезут не в своё дело, сидели бы программировали... Про то, что программист *должен думать* - вспоминают тогда, когда проект уже измучен подпорками, а те программеры,которые начинали проект, давно сбежали на рыбные места.

Да и по поводу ответственности программиста, по поводу того, что он "должен думать" и насколько от этого его думания зависит успех проекта в целом. Разумеется, я не спорю - каждый человек, не программист-дизайнер, каждый человек должен быть образован, эрудирован, соглашусь и с комментариями,которые озвучил ("Про пользу гумманитарных наук") недавно в своём блоге Аскар Байбузов:

Господа студенты-программисты. Вы наверное сейчас на чем свет стоит ругаете идиотов, которым в голову пришло в программу обучения технарей вставить такие гумманитарные и нетехнические предметы, как логика, социология, психология, правоведение, экономика, религиоведение, этика и эстетика. Конечно, гораздо ведь интереснее в это время изучать языки программирования, а потом гнуть пальцы перед друзьями, я мол знаю Яву или РНР. Конечно, эти предметы нередко преподают преподы что называется второго сорта, ибо знающий препод пойдет читать свой предмет в профильный вуз, а не к технарям. Но это не отменяет того факта, что предметы эти чрезвычайно полезны и нужны.
Вы ругаете на чем свет стоит логику? Однако не поленитесь, сходите в библиотеку, почитайте из каких этапов состоит решение логической задачи. Узнайте что такое системный подход. Вы можете "знать" любой язык программирование, но без системного подхода Вы так и останетесь обычным кодером. Собственно, если Вы уже изучили теорию программирования и умеете мыслить системно - совершенно по барабану какие языки программирования Вы знаете. Любой новый Вы сможете освоить за месяц максимум.
Вам кажется, что психология и социология - это для глупых блондинок? Однако подумайте, что в реальной жизни надо делать не курсовые и лабораторные в одиночку, а большие проекты целыми командами. Вам придется взаимодействовать с коллегами, разрешать конфликты и в дальнейшем, двигаясь по служебной лестнице, брать на себя руководство другими сотрудниками. Вы уверены, что Вашего здравого смысла хватит, чтобы осилить все это? Почему тогда так популярны книги ДеМарко и Рейнвотера?
Терпеть не можете экономику? А может Вам придется банковский или бухгалтерский софт писать? А там тысяча нюансов, и не всегда под рукой будет вменяемый аналитик. И сами бухгалтера далеко не всегда разбираются в том, чего они хотят от программы.
Этика и эстетика зачем? Объясняю. Несмотря на кажущуюся бездушность процесса программирования, на деле это довольно творческая профессия, так что чувство прекрасного хотя бы для того чтобы красиво оформлять код Вам явно не помешает. Ну и понимать, что этично, а что - нет, Вам тоже будет полезно для будущих гармоничных взаимоотношений в коллективе.

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

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

К примеру, контора А вырвалась вперёд конторы Б на 20% проектного и финансового уровня. По разным причинам:

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

А в это время в замке в некоей конторе Б - с меньшим уровнем проектов, зарплат и, возможно, худшими условиями труда, берут на работу программиста, ещё студента или младшего специалиста, ещё без скиллзов и реальных знаний. И вот он там трудится на скромной зарплате, читая по ходу дела документацию, обсуждая свои программерские проблемы на форумах и со старшими товарищами, делает один проект (с горем пополам, с матами PM и ежедневным недовольством заказчика), второй - уже покрасивше и по-увереннее, третий - вполне грамотно, успешно. Ему даже % на 10-20-30 повышают зарплату. И тут из конторы А, изначально более успешной, приходит информация о вакансии с з/п в два раза больше, главное условие - не ньюбам, а специалистам, которые уже имеют этот самый опыт. Долго будет раздумывать такой программер, оставаться ему в фирме Б в надежде, что она когда-нибудь вырастет до уровня А и его зарплата вырастет соответственно? Не-а, не долго, не больше 2-3 минут (собрать-обновить своё резюме и отправить по указанному адресу в фирму А заявку на собеседование).

Такое присходит постоянно. В сколько-нибудь крупном городе, где наличиствуют n-е количество подобных IT-контор, программеры мигрируют постоянно, и, причём, вовсе не всегда в одном направлении - вверх, потому что где гарантия, что в указанной выше фирме А не произойдёт креш, не уйдёт от них золотой заказчик и не наскучат они своему инвестору? Нет гарантий, потому и стабильности нет, и растут новые IT-конторы как грибы, и растворяются в неизвестности крупные фирмы, куда и попасть в своё время хотелось, и зарплаты там, и соцпакеты, и бассейн свой на крыше... где это всё?

Миграция же специалистов не приносит большой пользы никому, кроме самих специалистов (им- дополнительный опыт, динамика, способность быстро срабатываться с новой командой, но и здесь могут быть печальные исключения) - руководство фирмы может, разумеется, занимать позицию "мы никого не держим, если вас не устраивает зарплата - валите, других студентов наймём" - как я писала совсем недавно в одной из заметок про IT-офис. Но это всё внешнее, показное, никому не хочется быть перманентной стартовой площадкой для ньюбов и распускать спецов как только они чему-то научились.

Не так давно у нас ходил слух (вроде как не подтверждённый) о том, что ряд софтовых харьковских контор заключили между собой тайное соглашение, имеющее отношение именно вот к такой хаотичной миграции кадров. В частности речь шла о том, чтобы синхронизировать оплату программеров - junior developer'ов, senior developer'ов, аналитиков и дизайнеров - дабы не бегали за лишней сотней баксов к зарплате специалисты из одной конторы в другую, а если и объявлена по конкретной вакансии информация о зарплате большей, чем зарплата разработчика-специалиста в другой конторе (например, описанной Б, при этом состоящей в этой масонской группе, которая внутри себя поддерживает соглашение), то руководство Б может созвониться с руководством А и попросить - если специалист из Б по данной вакансии прийдёт на собеседование в А - чтобы его туда не брали. Уж не знаю, насколько это правда...

Это я всё к тому, что вчера переписывались с одним project-manager`ом не младшего звена из одной харьковской конторы - у них объявлены три вакансии разработчиков - сишников и дотнетчиков, он знает о моей конторе (фирма Б) и моих программерах, и просил... поискать среди наших желающих перейти к ним (фирма А). Разница про деньгам - именно те 10-20% вверх, по условиям труда - что-то лучше, что-то хуже, и я не враг людям, с которыми работаю, искренне желаю, чтобы зарабатывали они больше и работалось им легче... А вот жалко мне стало! Если согласятся уйти лучшие программеры - с кем останусь я? Худшие - с большой долей вероятности у них не пройдут собеседование (я до сих пор не понимаю, почему они сюда-то, в мою контору попали, тяжело с ними). Опять искать новых, опять обучать, срабатываться, закидывать ссылками на документацию, и после - отпускать в очередную фирму А на лучшие условия и большую зарплату? Тогда получается замкнутый круг для нашей конторы Б - на проектах студенческого уровня далеко не уедешь, а браться за серьёзные разработки - у разработчиков опыта не хватает, не успевают они его наработать, исчезают. А нет хороших заказов - нет повышений зарплат, условий труда и прочих радостей жизни.

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

С другой стороны - если упорядочить всё что можно - не занадто ли скучной станет жизнь разработчика?..

Н O B O C T И

:: Интернет по стандартам w3c
Несмотря на то, что эта бесплатная программа сочетает в себе возможности браузера и web-редактора, главное ее предназначение - проверка кода интернет-страниц....>>

:: Ежегодная международная конференция PHPCONF 2007 состоится в мае
Международный клуб разработчиков PHPCLUB приглашает веб-разработчиков принять участие в PHPCONF 2007 - ежегодной международной конференции web-разработчиков, которая состоится в мае 2007 года в Москве....>>

:: Готовится к выпуску девятая версия браузера Netscape
В официальном блоге разработчиков Netscape появилась предварительная информация о готовящейся к выпуску девятой версии этого браузера....>>

:: Oracle с интерфейсом Web 2.0
Oracle выпустила WebCenter Suite, инструментарий построения пользовательских интерфейсов, отображающих информацию, которая поступает из множества источников, и включающих в себя средства Web 2.0 - блоги, wiki и другие элементы...>>

:: Социальные сети по версии IBM
На конференции Lotusphere 2007 сотрудники IBM сделали целый ряд анонсов новых продуктов, многие из которых созданы на базе результатов работы исследовательского подразделения корпорации. В IBM подчеркивают, что ее средства поддержки совместной работы интегрируются или могут подключаться к продуктам Microsoft аналогичного назначения....>>

:: Открыта первая баннерная сеть для блоггеров
Создатели "Блоглента.ру" запустили первую в русскоязычном интернете баннерную сеть для блоггеров - Bloglife. Сеть Bloglife предназначена для тех, кто ведет stand-alone блоги, то есть блоги на собственных доменах....>>

:: Adobe Labs Flash Media Encoder - трансляция видеоматериалов в режиме реального времени
Компания Adobe выпустила первую предрелизную версию продукта Flash Media Encoder....>>

:: Девять советов для предпринимателей в Веб 2.0
Веб 2.0 – ныне очень популярное, новомодное словечко, однако никто полностью не уверен в его значении. Веб 2.0 имеет некое отношение к содержимому сайта, выбираемому самим пользователем, а также к взаимодействию среди пользователей, но разве это все?...>>

:: Code Contest - конкурсное программирование
Atlaskit - бизнес-сеть, о которой мы уже писали в прошлых обзорах, анонсирует проект "Code Contest" - конкурсное программирование....>>

:: РА "Артон" проводит практический семинар "Эффективная реклама в Интернете"
27 февраля агентство интернет-маркетинга "Артон" проведет очередной практический семинар "Эффективная реклама в Интернете"....>>

:: Adobe передает PDF в организацию по стандартизации
Adobe Portable Document Format (PDF), уже ставший неофициальным стандартом электронных документов, скоро получит официальное признание....>>

:: Сисадмины и юзеры вновь стали героями сборника курьезных историй
Совместный проект компаний Softline и Mail.Ru - сайт Софт@Mail.Ru анонсировал выпуск книги "Сисадмин и юзверь". Издание представляет собой сборник лучших материалов online-сообщества "Сисадмин тоже человек"...>>

:: IBM впрыскивает в Lotus дозу Web 2.0
В понедельник IBM представила новые продукты, предназначенные для переноса в деловой мир потребительских технологий, таких как блоги и веб-закладки....>>

:: Сайт Софт@Mail.Ru предоставил рейтинг самых популярных программ 2006 года
Совместный проект компаний Softline и Mail.Ru - сайт Софт@Mail.Ru - подвел итоги и предоставил рейтинг самых популярных программ 2006 года, представленных в каталоге портала....>>

С Т A T Ь И

:: Неэтичные методы рекламы и "пиара" в Интернете [Оптимизация сайтов]
Многие пользователи Интернета применяют неэтичные методы, не зная о возможных негативных последствиях (в том числе, уголовной ответственности). С другой стороны, знания о "грязных" методах позволят нашим читателям более эффективно им противостоять...>>

:: Миф о специалисте [Раскрутка сайта]
Обычному предпринимателю офф-лайн бизнеса очень трудно представить, как работает виртуальное пространство, возникшее изначально по прихоти программистов и программ, т.е. здесь нужны специалисты по электронной коммерции....>>

:: Page Promoter Bar – маленький друг Хомо Интернетикус [Оптимизация сайтов]
Информация, которую тулбар может извлечь из Сети и предоставить пользователю, позволяет принимать решения о направлении дальнейшей работы с веб-ресурсом как профессионалу-программисту, так и менеджеру интернет-проекта...>>

:: Хосты по осени считают, или Размышления об интернет-рейтингах [Раскрутка сайта]
Всевозможные рейтинги во всем мире не теряют популярности - всегда найдутся желающие чем-нибудь померяться. Какие данные учитываются счетчиками и каким образом определяется место в интернет-рейтингах?...>>

:: О хороших вещах и о том, как они появляются на свет [Web-дизайн]
Чем выразительнее и индивидуальнее дизайнер, тем ярче и богаче образы, которые он создает и отражает в своих работах. Именно поэтому создание хороших вещей подвластно только хорошим мастерам, вкладывающим частичку собственных ощущений и впечатлений в каждый штрих и полутон...>>

:: Опубликовано руководство по дизайну Веб 2.0 [Web-дизайн]
Как известно, концепция Веб 2.0 включает в себя не только социальные сети, генерируемый пользователями контент и активное применение Ajax, но и характерное, специфическое оформление. Догматических правил здесь нет, но у сайтов нового поколения действительно более эффективный дизайн....>>

Большее количество новых материалов вы найдете на сайте Библиотеки

У Л Ы Б Н И Т Е С Ь !

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

От создателей ГК РФ: Он не знает закона гравитации и считает, что это может осовободить его от отвественности за тех, кто летит с ним. Читайте только лицензионный - Незнайка на Луне

Они брали от жизни все. Подчинив своей власти всех и заставив служить себе. И только он, одинокий герой, которого предаст ученик способен встать у них не пути... Читайте! Серия мировых бестселлеров, изданных на сотнях языков - Ветхий Завет, Библия, Новый Завет а также издания молодых авторов из серии Евангелие!!!

• Предыдущий выпуск рассылки - № 216

• Обсудить этот выпуск рассылки можно в спецтопике нашего форума