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

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

 



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

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

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

Итак, краткое описание:
Для того, чтобы проверить текст нам нужно отослать его в POST на https://google.com/tbproxy/spell?lang=ru, где для смены языка следует заменить значение параметра lang на соответствующий по ISO 3166-1 alpha-2. Текст оформляется в XML вида:

<?xml version="1.0" encoding="UTF-8" ?><br/>
<spellrequest textalreadyclipped="0" ignoredups="0" ignoredigits="1" ignoreallcaps="1"><br/>
 <text>Текст для проверки</text><br/>
</spellrequest>

ignoredups — подсветка повторов
ignoredigits — считать цифры ошибками
ignoreallcaps — не проверять слова написанные капсом (подсказал pointum)

Если всё успешно, мы получаем ответ вида

<?xml version="1.0" encoding="UTF-8"?><br><spellresult error="0" clipped="0" charschecked="272"><br> <c o="27" l="13" s="0"></c><br> <c o="73" l="11" s="1">орфографии и орфографии</c><br> <c o="190" l="11" s="1">пользоваться</c><br> <c o="226" l="13" s="0">пред оставляет пред-оставляет</c><br></spellresult>

Атрибуты тега spellresult:
error — произошла ли ошибка
charschecked — количество проверенных символов

В нем идет перечисление допущенных ошибок (теги c), их параметры:
o — начало исходного слова в тексте
l — длина этого слова
s — точность результата

В самом теге c содержатся предполагаемые варианты написания слов, разделенные символом \t.

P.S. Когда этот текст уже был написан, случайно наткнулся на статью в блоге Paul Welter, которая, в принципе, описывает тоже самое…


UPD: Пользователь wayly написал на PHP класс для проверки текста с помощью этого сервиса, скачать можно по ссылке proxysoft.ru/files/spellchecker.zip (зеркало).

UPD2: mezhevikin подсказал ajax-решение с использованием этого сервиса — orangoo.com/labs/?page_id=3

UPD3: Список поддерживаемых языков

_________
Текст подготовлен в ХабраРедакторе
Код подсвечен в Source Code Highlighter

Бывает у вас так, что дизайн разработан отличный, всю эту красоту технично собрали и заанимировали, а вот прелоадер как то остался на последнюю очередь и силы уже иссякли… А если учесть, что это первый элемент который встречает посетителя, то положение приобретает серо-тоскливые оттенки.

Специально для попавших в такую ситуацию, ресурс для вдохновения (подчеркиваю!) prettyloaded.com

Это продолжение, а точнее развитие, статьи написанной ранее.

В результате небольшого рефакторинга, получилось повысить производительность, и упростить код. Результатом стало изменение перечня используемого софта.

Эта статья продолжение первого варианта файлового менеджера.

FCKfsys — файловый менеджер для визуального редактора для web FCKeditor. Мне в FCKeditor все нравится, кроме файлового менеджера. Так что надо както исправлять это самому.
Подробная информация о плагине на моем сайте и там же можете посмотреть пример работы.

Выглядит файловый менеджер с превьюшками:



UPD: Доработки сделаны, теперь надо над интерфейсом поработать. По моему ориентир должен быть на Windows-проводник, чтобы было привычно. То есть немного причесать надо.

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

Непопулярные аспекты тестирования

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

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


(НЛО прилетело и растянуло этот рисунок здесь)

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

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

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

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

Здесь я попытаюсь ответить на эти вопросы, рассмотрев:

• Причемущества от наличия SSL вообще, и подписанного сертификата в частности.
• Типы SSL-сертификатов.
• Пути их получения.

Я не претендую за 100% верность данной статьи, она основана только на моем мнении и личном опыте :)

В этой статье мы пройдём с вами полный цикл от идеи, проектирования БД, написания PHP-Кода, и завершающей оптимизации. Постараюсь рассказать обо всем, как можно проще. Использовать для примеров буду PHP и Mysql. Заодно потренирую новичков :).

В этой статье я коснусь вопросов:
  1. Идея ACL
  2. Проектирование БД
  3. Нормализация БД
  4. Рефакторинг кода
  5. Оптимизация рабочего кода

Статья является ответом на Бинарное распределение прав доступа в CMS. Пока автором пишется практическая часть, я хочу предоставить мой вариант, который я использую довольно давно.
То, что я сейчас расскажу, похоже на ACL.

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

На Хабре есть фишка связанная с ним, если в профиле ввести свой Twit-аккаунт, то последнее сообщение будет стоять у вас в статусе — мелочь, а приятно, не нужно делать одно и тоже дважды.

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

В техническом исполнении все оказалось не сложно.

Чтобы получить содержимое веб-страницы все с удовольствием используют file_get_contents(), например file_get_contents('http://www.habrahabr.ru/'). Но я уже давно наблюдаю, что, как дело доходит до того, чтобы отправить POST, разработчики используют либо CURL, либо открывают сокеты. Я не считаю, что это плохо или что не надо так делать, просто для решения простых задач можно использовать простые решения.

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

file_get_contents() принимает 3 параметром «контекст», который собственно и конфигурирует сам запрос.
Ниже пример такого запроса или RTFM

Психологи утверждают, что молодой, энергичный и амбициозный человек (а других вряд ли станут рассматривать на должность менеджера проекта) “выдерживает” на одном рабочем месте не более 5-6 лет. А для некоторых психологических типов этот срок составляет 2-3 года. Практический опыт чаще всего подтверждает эту позицию. Далее менеджеру проектов требуются новые перспективы, причем далеко не только финансовые.

Переход менеджера на новую работу — серьезный поступок, требующий взвешенного решения и тщательной подготовки. Ведь, как правило, есть что терять на том месте, где вы уже работаете. Одновременно, на новом месте всегда ждет риск. Работа менеджера проекта сродни работе футбольного тренера. Так же как и в футболе, в провале проекта будет виноват его менеджер, какими бы “объективными” ни были обстоятельства поражения. Обстоятельства надо изучать заранее и обсуждать их со своим, пока еще будущим руководством.

Главное что надо понять, прежде чем согласиться заняться проектом, это что от вас хотят и что вы сможете сделать. Понять все на 100% вряд ли удастся, но разобраться необходимо. В конце концов, представляя объем работы, легче торговаться изза зарплаты и бонусов. Предлагаю свой список, “Абсолютный минимум” шагов, которые надо предпринять до того, как сказать “да” и выйти на работу в новую команду. Ответьте “да” или “нет” на следующие вопросы:

1. Представляете ли вы себе структуру компании?
2. Знаете ли кому будете подчиняться и с кем будете взаимодействовать внутри компании?
3. Одинаково ли понимаете с вашим будущим руководством роль менеджера проекта?
4. Видит ли ваше будущее руководство перспективы ваших проектов через год?
5. Владеете ли вы методами и инструментами управления проектами, которые применяются в компании?
6. Знаете ли вы как принято документировать проект в компании?
7. Для каждого порученного вам проекта существует документация?
8. Для каждого порученного вам проекта существует план работ?
9. Существует ли отдел контроля качества?
10. Ознакомились ли вы со списком ошибок по вашим проектам в системе багтрекинга?
11. Ознакомились ли вы с резюме каждого участника вашей будущей команды?
12. Знакомы ли вы с лидером вашей команды?
13. Ознакомились ли вы со списком требований к проектам?
14. Ознакомились ли вы с общей архитектурой каждого из ваших будущих проектов?
15. Знаете ли вы заказчика вашего проекта?
16. Существует ли представитель заказчика?
17. Знаете ли вы кто был предыдущим менеджером проекта?
18. Знаете ли вы кто должен передать вам дела по проектам?

Список получился длинным, но я скорее соглашусь добавить еще пунктов, чем что то выкинуть. На все вопросы можно ответить “да” или “нет” и подсчитать количество положительных ответов. Сколько вам нужно положительных ответов чтобы согласиться на новые проекты — выбирайте сами. Тут многое зависит от индивидуального темперамента и от предлагаемой компенсации. Да много еще от чего зависит.
Чтобы ответить на все вопросы, надо серьезно поработать и изрядно потратить времени. Не всегда это время есть, особенно когда на переговоры приходится ездить в другой город. Если вы получите утвердительный ответ на все 18 вопросов, вы имеете отличные шансы на успех. Вопросы 2,3, 13, 15, 16 являются наиболее критичными, и, в случае отрицательного ответа хотя бы на один из них, надо очень осторожно давать согласие на новую работу. В этом случае вы исключительно рискуете.

Удачного старта!

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

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

Удивились мы настолько, что сели и сделали bubuki.ru – площадку для покупки/продажи подержанных ноутбуков.

Введение

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

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

«Совершенный Ajax» — новый подход к построению web-приложений, при котором web-сервер не генерирует ни строчки HTML-кода и взаимодействует с внешним миром только посредством web-служб; а клиентский интерфейс реализуется только на основе клиентских HTML, CSS, JavaScript.

Статья состоит из двух частей. В первой части — более живой и провокационной я постараюсь заинтересовать проблемой, рассказать о технологии «Совершенный Ajax» и показать ее применение на примере нашего проекта «Система Интерактивного Тестирования Знаний “Синтез”» (который имеет ряд интересных особенностей, таких, как использование серверного JavaScript на платформе Mozilla Rhino, прототипно-ориентированная ORM и поддержка SPARQL — языка запросов к Semantic Web).

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

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


Попробуйте угадать: к какой архитектуре относятся web-приложения?

К клиент-серверной говорите? Я ожидал, что Вы так ответите :-)

Что ж, давайте разберемся. В клиент-серверной архитектуре выделяют:

• Сервер — отвечает за хранение данных и реализацию бизнес-логики приложения.
  
  
• Клиент — отвечает за взаимодействие с пользователем ^[1].
  
  

Реализация бизнес-логики на сервере и взаимодействие с пользователем на клиенте четко разделены.

Преимущества клиент-серверной архитектуры очевидны; мы их все знаем:

1. Бизнес-логика не смешивается с пользовательским интерфейсом.
2. Можно реализовать несколько клиентов с разными пользовательскими интерфейсами: интерфейс командной строки, оконный Windows-интерфейс, Flash, web-интерфейс, мобильный интерфейс и т.д.
3. Клиентский компьютер не требователен к ресурсам;
4. И т.д.

Но, относятся ли web-приложения к клиент-серверной архитектуре?

Действительно, в web-приложениях есть сервер, отвечающий за бизнес логику приложения.

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

Клиент, т.е. браузер лишь визуализирует уже готовый HTML-код интерфейса. Это, фактически, то же самое, что прицепить к серверу монитор и объявить этот монитор клиентом…

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

Что такое представление?

Представление (VIEW) — объект базы данных, являющийся результатом выполнения запроса к базе данных, определенного с помощью оператора SELECT, в момент обращения к представлению.

Представления иногда называют «виртуальными таблицами». Такое название связано с тем, что представление доступно для пользователя как таблица, но само оно не содержит данных, а извлекает их из таблиц в момент обращения к нему. Если данные изменены в базовой таблице, то пользователь получит актуальные данные при обращении к представлению, использующему данную таблицу; кэширования результатов выборки из таблицы при работе представлений не производится. При этом, механизм кэширования запросов (query cache) работает на уровне запросов пользователя безотносительно к тому, обращается ли пользователь к таблицам или представлениям.

В одной из своих статей (Как играть в «программирование» или путь программиста), я писал про пять стадий развития программиста, и вот четвертую стадию назвал «Мания величия». С тех пор прошло пару месяцев, а я все больше убеждаюсь, что это истинная правда! Собственно в очередной раз я убедился в этом прискорбном факте вчера, когда решив забить на фриланс, обратил внимание на только что появившуюся студию, куда меня звали работать web-программистом на довольно приличную зарплату. Мои отношения с начинающими студиями – это отдельная тема, вечно меня притягивает ко всему «начинающему», видимо организаторские потребности дают о себе знать… но статья не о том, так вот, придя на собеседование, я познакомился с их программистом, назовем его… ну пусть будет Виталий.