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

Я составил список из 25 золотых (ИМХО и только ИМХО) деловых книг.

Развитие блоггинга.
Блог, дневник, блогосфера — эти слова уже успели стать нормой для любого человека хоть чуть-чуть знакомого с интернетом.
А почему бы и нет? Ведь это отличный способ донести информацию до общественности, узнать о происходящих событиях на любую тему из первых рук, да и рассказать о своей нелегкой судьбе тоже многие не прочь. Сейчас блоги ведут не только простые смертные интернет-пользователи, но и политики, музыканты и руководители крупных компаний. Но даже блоггинг не стоит на месте, меняясь с каждым днем, он приобретет различные формы, и о том какие именно, я хочу вам рассказать.

С появлением термина Web 2.0 стали популярны веб-сервисы, предоставляющие некоторые функции по обмену информацией между разными сайтами и серверами. Появилась возможность размещать данные сразу в нескольких источниках, считывать их и, возможно, опять пересылать.

В связи с этим, я думаю, у всех на слуху такие технологии, как XML-RPC, SOAP и, наверное, REST? Нет? Не слышали про REST (Representational State Transfer)? Чтобы в голове немного прояснилось, про саму технологию можно прочитать статью «REST как альтернатива SOAP» или посмотреть ролик о реализации взаимодействия на Ruby.

Приведу небольшой, но очень показательный пример взаимодействия с del.icio.us на PHP.

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

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

Проблемы при использовании MySQL можно разделить на следующие три группы(в порядке значимости):

1. Неиспользование или неправильное использование индексов.
2. Неправильная структура БД.
3. Неправильные \ неоптимальные SQL запросы.

Остановимся на каждой из этих групп подробнее.

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

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

Разумеется, вы можете воспользоваться Flash, Silverlight или Java-апплетами, однако в этом обзоре я хотел бы вам показать библиотеки визуализации, написанные на чистом JavaScript.

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

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

Введение.
Вот уже 5 лет я занимаюсь веб — разработками. За это время приходилось и на коленке делать сайты за несколько сотен долларов и участвовать в довольно крупных проектах. За последний год меня не оставляет ощущение deja vu. Где-то я уже видел: нервных заказчиков, взбешенных менеджеров, заваленных работой разработчиков и сорванные сроки. При этом для меня ничего не изменилось. Были все те же нечеткие, постоянно изменяющиеся требования, прессинг, и ни одного проекта, сданного в срок…
И это, не смотря на то, что “грабли” были всегда одни и те же.

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

При создании объекта есть два способа описать требования: «что должен уметь/делать объект» (описание цели) и «каким должен быть объект» (описание реализации). Прощу прощения если формулировка не точна, источника сией мысли я не знаю, формулирую сам. Далее речь пойдет о втором способе описания объекта — дизайна сайта.

Перевод отличной статейки. Думаю, будет полезна как новичкам, которые только приступили к использованию jQuery, так и тем, кто уже какое-то время с ним работает. А кого-то, возможно, заставит глянуть эту чудесную библиотечку. Многие советы имеют отношение не только к jQuery, но и к JavaScript в целом. Лично для меня была весьма и весьма познавательной, посему и захотелось донести это «до масс». Перевод не дословный, но передающий смысл и максимально адаптированный к русскому языку.

Далее все написано от имени автора оригинальной статьи.

Введение

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

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

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

Содержание

1. Загружайте фреймворк с Google Code
2. Используйте «шпаргалку» (cheat sheet)
3. Соединяйте все ваши скрипты и уменьшайте размер файла
4. Используйте возможности Firebug для ведения логов
5. Минимизируйте операции выборки в пользу кэширования
6. Сводите манипуляции с DOM-деревом к минимуму
7. Оборачивайте все в единый элемент, когда речь идет о любой вставке в DOM
8. Используйте «id» вместо классов, где это возможно
9. Задайте контекст своим селекторам
10. Используйте последовательности вызовов методов с умом
11. Научитесь правильно использовать анимацию
12. Научитесь назначать и делегировать события
13. Используйте классы для сохранения состояния
14. Еще лучше — используйте встроенный в jQuery метод data() для сохранения состояния
15. Пишите собственные селекторы
16. Подготавливайте HTML и модифицируйте его, когда страница загружена
17. Используйте «отложенную загрузку» (lazy loading) для определенного контента для выигрыша в общей скорости и преимуществ для SEO
18. Используйте служебные функции jQuery
19. Используйте «noconflict» для переименования глобального объекта «jquery», когда используете его с другими фреймворками
20. Как узнать что картинки загружены?
21. Всегда используйте последнюю версию
22. Как проверить, что элемент существует?
23. Добавляйте класс «JS» в элемент «html»
24. Возвращайте «false» для отмены поведения по-умолчанию
25. Короткая запись для события готовности документа

О чём речь?

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

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

В этом обзорном посте я бы хотел рассмотреть незаметные для пользователя методы защиты от ботов.

Методы защиты

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

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

Суть концепта: плеер грабит плейлисты на аудиохостингах. Например, указав адрес vkontakte.ru/audio.php?xxxx, все композиции попадут в плейлист плеера, которые можно удалить, поменять местами и прослушать, не заходя на сайт.


1. Свернутый портативный режим

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

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

 



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

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

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

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

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

Запомните! Человек бездумно принимающий лекарство — это обезьяна с гранатой. Может навредить себе и окружающим.

Программирую на Java вот уже 7 лет. Но на работе часто приходится обучать новое поколение. В связи с этим и решил сделать некоторую шпаргалку, которая, надеюсь, пригодится и для хабрчан. Если кто-то может помочь дополнить чем-то информацию из этой статьи, то пишите! Итак:

Основные ресурсы для начального обучения

• www.javable.com — сайт со статьями и tutorial'ом по Java. Все в основном на русском.
• www.exampledepot.com — очень полезный ресурс, где собраны краткие примеры использования классов для тех или иных пакетов
• java.sun.com — без первоисточника не обойтись. Для любого Java программиста JavaDoc должен быть истиной в последней инстанции. Так же здесь можно найти серию tutorial'ов на все возможные темы.

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

На написание этого текста меня натолкнули постоянные споры, возникающие за время моей практики как веб-дизайнера. Собственно, первый раз мне пришлось столкнуться с «резиновыми сайтами» благодаря прихоти заказчика. Когда дизайн проекта был полностью готов, а сам сайт сверстан и подключен, заказчик спросил: «А почему он не растягивается?». Было это достаточно давно, но этот вопрос я слышу примерно раз в 4-5 месяцев. О «резиновой» верстке сайтов говорили и писали много. Говорили что она обязательна, и наоборот, что использование ее ошибка. Однозначно, были причины возникновения резиновости. И утверждать, что использование этой технологии на 99% ошибочно, однозначно нельзя. Любую технологию нужно применить, если она нужна. Я хочу очертить примерную границу применения резиновой верстки.

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

Проблема

На многих сайтах я наблюдаю следующий процесс:

1. Пользователь заходит на сайт
2. Пользователь находит что-то, что он хочет купить/скачать/сохранить
3. Пользователь переходит на страницу регистрации
4. Пользователь вводит свою информацию и ждёт письма с ссылкой активации
5. Пользователь получает письмо и переходит по ссылке
6. Пользователь попадает либо на страницу активации, либо на страницу логина, либо на страницу, откуда он начал регистрацию
7. Пользователь снова находит то что он хотел купить/скачать/сохранить
8. Пользователь покупает/скачивает/сохраняет

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

Решение

Решили мы как то с приятелем, запустить стартап не стартап, а так, сайт для души. Решили — значит будет запущен. Бюджет… А давай не купим ещё по 2 кружки пива, на это и запустим. В общем денег на домен да на виртуальный хостинг на валуехосте. Так люди мы «взрослые», и делать всё привыкли основательно, нам нужна система управления версиями и выкладыванием. Было решено поднять subversion репозиторий с возможностью раздачи доступа к нему нескольким разработчикам с разными логинами на valuehost. Но у нас виртуальный хостинг со всеми его ограничениями, что делать?