Существует много разных способов css разметки. Некоторые базируются на абсолютном позиционировании, другие используют float'ы. Первый метод плохо поддерживает «резиновость» макета, тогда как второй это неплохой способ разметки.

Но, как и многие мощные инструменты, float'ы имеют свои изъяны. Для начала, верстка на основе float'ов не такая простая к пониманию, а также float'ы есть источником многих багов (в основном в ИЕ), что делает их не идеальным вариантом в погоне за кроссбраузерностью.

Итак, речь далее пойдет о

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

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

Конструирование ПО

Что такое конструирование ПО?

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

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

Не знаю почему, но на эту важнейшую технологию обращают так мало внимания. Я хочу несколько исправить положение, поэтому это — первая статья в цикле «Кодогенерация». При рассмотрении данной темы будет использован язык PHP и БД MySQL, но кодогенерация сама по себе возможна на любом языке и с использованием любой БД, просто на PHP мне будет проще объяснять некоторые важные моменты. Так же я буду обращать внимание на состояние дел в других системах и языках.

Данная статья посвящена одному вопросу: какие проблемы присутствуют в современном программировании.

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

Что такое DOS?

• плата в компьютере;
• фирма, выпускающая компьютеры;
• марка компьютера;
• программа;
• тип процессора.

Варианта «операционная система» не предусмотрено. Вообще. Отвечай, как хочешь, все равно ошибешься.

PHP один из самых популярных скриптовых языков программирования. Почти 60% веб серверов используют PHP.Миллионы веб-сайтов и веб-приложений разрабатываются на PHP каждый месяц.

PHP изначально разрабатывался как простая замена языку Perl, и уже спустя пару лет он стал чрезвычайно мощным и популярным. Язык PHP, сам по себе очень похож на ANSI C.
Одна из причин почему PHP стал таким популярным это его короткий период обучения.

Изучение PHP абсолютно не тяжёлое занятие, особенно если вы хорошо знакомы с синтаксисом Java или C.

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

Очень часто задают вопрос о том, где можно почитать по стартапам.

Могу порекомендовать три книжки:

High Tech Start Up, Revised and Updated: The Complete Handbook For Creating Successful New High Tech Companies, John L. Nesheim

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

Founders at Work: Stories of Startups' Early Days, Jessica Livingston

Книга содержит интервью с основателями известных стартапов, хорошо раскрывает проблемы, которые стояли перед ними, и как они достигли успеха, преодолев их. Кстати, первое интервью с создателем PayPal – Максом

В предыдущей статье о моём методе оценки эффективности сотрудников я отвечал на письмо уважаемого мной человека. Признаюсь, я немного слукавил :). Если быть точным, Subject письма был: «мотивация ИТ». Далее в письме вопросы ставились иначе, речь шла о KPI, на мой взгляд, это совершенно разные вещи. То есть я отличаю понятие Мотивация и Критерии эффективности.

Первую часть читайте здесь.

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

Тем, кто занимается бизнесом, в частности веб-разработкой, не надо рассказывать о «вредных» клиентах. Мой комментарий на эту тему в одном из топиков вызвал положительные отклики, поэтому расскажу, что я думаю по этому поводу. А именно: как дифференцировать клиентов по «вредности»; как (и стоит ли) работать с «вредными клиентами».

Позднее Статическое Связывание (Late Static Binding, LSB) является бурно темой обсуждений последние три года в кругах разработчиков PHP (и наконец мы его получили в PHP 5.3). Но зачем оно нужно? В данной статье, как раз и будет рассматриваться, как позднее статическое связывание может значительно упростить ваш код.

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

1) Какой бы ерундой вы не занимались с PHP, узкое место _всегда_ — БД. PHP — он как Буратино — тупОЙКАк… дрова. Lighttpd и Nginx позволяют разнести его по множеству физических серверов на раз без шума и пыли. Зарплата адекватного спеца по PHP в Москве — 30-45 тыс. рублей в месяц, стоимость аренды нормального сервера — от 3 тыс. рублей в месяц. А вы не знали ;)?

2) Какой бы ерундой вы не занимались — 30-60% производительности (возможно и больше) PHP-кода решит правильно выбранный и настроенный акселератор.

3) Серебряной пули нет. Не важно, какой концепт вы применяете — строгое ООП (в стиле Zend Framework), функции в стиле PHP4 (или ограниченное ООП) или вообще лапшу в стиле «PHP для чайников» — ни одна из этих парадигм не даст ощутимый прирост производительности, если конечно ваши программисты не выше как минимум на голову.

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

1. Деньги.

Первым вариантом ставлю деньги, завлечение деньгами. Это, наверно, самый логичный но наименее распространенный вариант. Во-первых, не каждый «зеленый» проект сможет платить нормальные деньги, ибо нужен не плохой буфер. Зачастую владельцы проектов — свободные разработчики, у которых нет лишних 2-3 тыщ зеленых в месяц на свой зеленый проект. Во-вторых, я лично не видел еще ни одной нормальной компенсационной программы, точнее её реализации для сети. Идеальная — установка AdSense от гугля. В идеале — пользователь ставит свой AdSense код в свой контент (блог, новости) и получает 100%, оставляет AdSense проекта и получает 50% (скажите, стали бы вы больше писать, если бы за каждый просмотр вашей новости на хабре вам капала копеечка?)

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

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

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

В сети доступно масса документации по языку XSL. Данный раздел не претендует на роль документации по языку, а лишь кратко, по шагам объясняет, как создать свой XSLT-шаблон.

Описанная ниже схема успешно мною используется уже более 3 лет. По началу я к XSLT относился с большой опаской (особенно, когда разбирал чужие исходники), однако однажды поняв, что к чему, уже не представляю, как без него можно работать.

MoreCSS — небольшая библиотека JavaScript, весом всего 14кб, для решения повседневных задач, таких как создать всплывающие окна, сделать вкладки меню, таблицы и списки с оформлением «зебра»-стиль… и т.д. С помощью этой библиотеки Вы сможете это делать средствами обычного css.

После статьи «Разгоняем CSS-селекторы: стоит ли?» было предложено рассмотреть несколько дополнительных случаев, учитывающих транзитивность селекторов (например, насколько быстрее a c, чем a b c, или наоборот). Данное исследование посвящено как раз разбору таких случаев.

Методика

Методика и уменьшение погрешности подробно рассматривались в первой статье, на них сильно много останавливаться не буду. Скажу лишь, что при наращивании количества классов и идентификаторов Opera стала значительно медленнее (раза в 3) отображать код (при этом общий его объем увеличился примерно в 1,5-2 раза). Скорее всего, в следующую статью войдет исследование влияния количества классов/идентификаторов/размера кода на общую производительность браузера.

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

читать дальше на webo.in →

Примечание: ниже перевод презентации «High Performance Ajax Applications», подготовленной ведущим специалистом из Yahoo (а теперь уже из Apple) Julien Lecomte. В ней автор освещает некоторые аспекты оптимизации как JavaScript-приложений, так и веб-сайтов вообще. В целом, советов много, и почти все, действительно, по делу. Однако, встречается и откровенная реклама Yahoo :) Мои комментарии далее курсивом.

Часть 1. Разработка для высокой производительности

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

• Ориентируемся на производительность с самого первого дня
• Тесно работаем с дизайнерами и менеджерами продукта
• Понимаем рациональность дизайна
• Объясняем компромиссы между дизайном и производительностью
• Предлагаем альтернативы и показываем, что еще возможно (на уровне прототипа)
• Пробуем силы в реализации нетривиального дизайна (нельзя сразу говорит «нет»)
• Помогаем упростить дизайн и взаимодействие с пользователем (добиваемся компромисса)

читать дальше на webo.in →

Проблема (хотя и не для всех): в текущей реализации Хабра ссылку (ответить) в комментариях невозможно открыть в новом окне. Достигается этот эффект так:

<a href="javascript:saw(703108);">ответить</a>

Но есть более универсальное средство, подсмотренное в livejournal:

<a onclick="javascript:return saw(703108);" href="***.html?replyto=703108#703108">ответить</a>

[+] удобство комментирования (DHTML) остаётся, при этом…
[+] cсылки не теряют своих привычных свойств (зависящих от браузера, кстати)
[+] устраняется зависимость от JavaScript
[-] надо что-то менять :)

UPD от 11 марта: FWIMC, меня интересуют только мыши сохранение обычных свойств ссылок; пюризмом реализации не интересуюсь.

Давеча интересная беседа по ICQ случилась — об «адекватной» стоимости веб-разработки.

Человек поинтересовался стоимостью разработки одного сайта, который мы недавно сдали. Здесь нужно отметить, что данный проект был довольно сложный, пришлось создавать программные модули с нуля. Не вдаваясь в подробности диалога, разница в предложенном мною [1] и ожидаемом «заказчиком» [2] бюджете оказалась большой. Разов этак в 8 примерно выше [1] над [2].

И тут мне очень захотелось узнать: из каких это соображений заказчик устанавливает цену, которая абсолютно не отражает реальную ценность данной работы?