Введение

Все началось с того, что я стал системным администратором у одного провинциального Интернет-провайдера. Помимо администрирования различного рода ресурсов, мне в присмотр достался один молодой, но бурно развивающийся ресурс. Ресурс представлял из себя классический LAMP проект. Сайт, на котором генераторами контента являлись обычные пользователи.
* К слову, в то время я ничего не понимал в *nix системах, хоть и все сервера которые мне достались, были именно на нем, разбирался я во всем этом достаточно быстро.

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

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

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

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

Порой мы отображаем на сайтах контент с других ресурсов: картинки или фавиконы. Некоторе браузеры просто оставят пустое место (Firefox), другие же отобразят уродский прямоугольник, явно указывая, что чего-то не хватает (IE). Как же можно средствами PHP проверить существование файла.

Есть функция file_exists(), но она хороша только для файлов в пределах нашей файловой системы, а с удаленным сервером не пройдет.

Есть вариант открывать файл на чтение и в случие ошибки констатировать факт, что файла не существует:
<?
// файл, который мы проверяем
$url = "http://url.to/favicon.ico";

// пробуем открыть файл для чтения
if (@fopen($url, "r")) {
echo "Файл существует";
} else {
echo "Файл не найден";
}
?>


Однако такой прием занимает достаточно много времени.

Есть вариант еще лучше — использовать функцию get_headers():
она делает запрос к файлу и получает все заголовки с ответом примерно в таком массиве
Array
(
[0] => HTTP/1.1 200 OK
[1] => Date: Sat, 29 May 2004 12:28:13 GMT
[2] => Server: Apache/1.3.27 (Unix) (Red-Hat/Linux)
[3] => Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT
[4] => ETag: "3f80f-1b6-3e1cb03b"
[5] => Accept-Ranges: bytes
[6] => Content-Length: 438
[7] => Connection: close
[8] => Content-Type: text/html
)


Как мы видим, в нулевом элементе есть код ответа, 200 значит, что файл существует, и мы спокойно можем получить к нему доступ.
Вот код, который проверит существование файла.

<?
// файл, который мы проверяем
$url = "http://url.to/favicon.ico";
$Headers = @get_headers($url);
// проверяем ли ответ от сервера с кодом 200 - ОК
//if(preg_match("|200|", $Headers[0])) { // - немного дольше :)
if(strpos('200', $Headers[0])) {
echo "Файл существует";
} else {
echo "Файл не найден";
}
?>


Теперь сравним по времени два метода с существующей favicon и с несуществующей:
при несуществующем файле второй метод (get_headers) выигрывает на две сотые секунды.
при существующем файле оба метода показали примерно одинаковое время.

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

Все знают этого «дядю» по изображению на стодолларовой купюре. Почти все знают фразу «Время — деньги», которую однажды Бен Франклин произнес. Есть много фактов из его интересной и удивительно жизни. Большинство людей не знают, что Франклин таки не был президентом США, хотя и очень активно участвовал в написании Конституции Америки. Много всяких слухов есть о масонстве, мировом порядке и так далее. Больше информации о нем можно прочесть в статье Википедии

Я бы хотел сегодня привести очень интересный отрывок из его дневника. Сегодня модно писать о том, как многое успевать, как быть эффективным, ка организовать бизнес и т.д. и т.п. К сожалению, как заметил Стивен Кови в своей книге «7 навыков высокоэффективных людей» (сам бы в жизни не читал по причине такого названия, но друг очень рекомендовал, прочитал книгу, очень доволен) сегодняшняя литература об управлении и личной эффективности сводиться к простому выписыванию рецептов решения стандартных проблем. Что-то типа аспирина на все случаи жизни. Редко встретишь книгу или статью затрагивающую глубинные мотивы, принципы внутренней жизни и целостности человека. Но сейчас не об этом… Хочу поделиться отрывком из дневника Франклина. Этот человек много достиг, поднялся с низов общества не имея официального образования, уверен, что много можно почерпнуть из его жизни.

Здравствуйте.
Сегодня я хочу рассказать об ошибках, которые часто совершают начинающие руководители и о простых способах их избежать.
Итак, Вы открыли студию. Проблемы с арендой офиса, первыми заказами, подбором команды, позади, что дальше?
Для студии первый год – самый сложный и показательный период, от которого зависит ее дальнейшее существование и успех. Очень многие руководители бросали свои начинания именно в первый год, к сожалению пройдя практически идентичный путь типичных ошибок.

Итак, первая ошибка. Клиент – враг.

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

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

Всегда объясняйте клиенту, зачем вы спрашиваете о бюджете

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

Джон, в свою очередь, с подозрением относится к вашему вопросу. Зачем вам знать о его бюджете? Единственная убедительная причина, которая приходит ему в голову – вы не хотите случайно назвать цену меньше той, которую он готов заплатить. Кроме того, он и сам не знает, какой у него бюджет. Откуда ему знать, сколько стоит сайт?


Клиент не должен думать, что вы выманиваете у него деньги.

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

ОФФТОП: Хочу выразить свою благодарность, всем кто плюсанул мой предыдущей пост и карму, это позволило мне пригласить на Хабр еще несколько хороших людей.

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

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

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

«Не стоит вести себя на работе слишком серьезно» — советует Мартин Звиллинг, предприниматель и консультант целого ряда стартап-проектов.

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

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

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

Разберемся почему так и как с этим жить.

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

Часть I — Часть II — Часть III — Часть IV — Часть V — Часть VI

Часть V

Очевидно, что в сфере высоких технологий развитие зачастую происходит быстро и бурно. Так произошло и со средствами отображения информации. В течении каких-то двух-трёх лет обычные ЭЛТ-мониторы почти целиком и полностью были вытеснены стремительно дешевеющими ЖК-собратьями. Что позволило существенно улучшить как геометрию отображения, так и цветопередачу, а также снизить утомляемость глаз за счёт отсутствия вредного мерцания. И если несколько лет назад подобное утверждение в пользу TFT-панелей можно было бы оспорить, то теперь этот факт не вызывает ни у кого сомнений: ЖК-дисплеи намного лучше для повседневной работы рядового пользователя. В связи с этим фактором возникла необходимость поиска качественно новых алгоритмов отображения шрифтов. Одно из таких решений пусть не сразу, но всё же получило определённое признание в среде пользователей, и на сегодняшний день является чуть ли не самым популярным на современных платформах. Речь, конечно же, о технологии рендеринга ClearType, которая послужила причиной разработки новых веб-ориентированных шрифтов…

Сейчас я на простом примере продемонстрирую одну их наших «микроинтерфейсных» находок.

Если товар добавлен в корзину, то вопрос с содержимым блока снимается. Пишем, сколько там товаров, на какую сумму, даем ссылку на оформление заказа.

Вторая версия статьи, расширенная и дополненая.

Большая часть готовилась для моего выступления на «РИТ: Клиентские технологии», куда я, к сожалению, не доехал.

 



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

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

Здравствуйте, хочу написать цикл статей про юзабилити веб-интерфейсов, и начну, как не странно, с корзины покупок.

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

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

Итак, начнем!

Добрый день, друзья, хочу поведать вам один секрет, который помогает мне быстро и правильно найти цветовую схему для сайта.Прошу строго не судить, возможно, некоторые из вас знают этот прием, но вот мой друг, не знал, а когда я поведал ему, как легко найти цвета для цветовой схемы сайта – он был поражен простотой решения. Я не претендую на уникальность, либо открытие нового метода, просто я это знаю, и мне это помогает.
Для того чтобы нам создать цветовую схему. Нам понадобится такая хорошая программа, как Adobe Photoshop, причем подойдет практически любая версия. Особых знаний работы с фотошопом для этого т.с. трюка не НАТО, все делается буквально в пару кликов.