Не секрет, что на ebay, DX, KD и прочих онлайн-магазинах существует много гаджетов и товаров, которых в РФ не найти. Чтобы удовлетворить свои гиковские потребности, а также просто тратить с умом, рано или поздно приходится обращаться к интернет магазинам. Однако новички теряются во всех этих «палках, клеймах, лотах, диспутах, EMS, USPS и прочее», а также некоторые не владеют английским для того, чтобы элементарно зарегиться в paypal.
Для этой цели админом форума ebay-forum.ru был создан подробнейший pdf-мануал, с которым я и предлагаю всем желающим ознакомиться.

Хочу представить на суд хабрасообщества концепцию информационной системы.

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

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

На данный момент существует несколько классов информационных систем:

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

Сразу поясню, что эти советы/правила больше относятся к саппорту через HelpDesk или e-mails, у телефонной поддержки есть некоторые свои особенности.

1. Быстрая реакция и ответы

Клиенты любят быстрый саппорт, они его обожают. Из-за быстрого саппорта они могут закрыть глаза на многое: на высокую цену продукта, ваши ошибки, баги софта. Чем быстрее отвечает и решает проблемы ваш саппорт — тем лучше.

К сожалению быстрый саппорт, доступный 24/7, это дорого: нужно больше людей и нужна круглосуточно доступная инфраструктура. Чаще всего это просто невыгодно, особенно если вы не крупная корпорация, а маленький стартапчик.

В этом случае нам поможет одна интересная штука.

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

Это правило поможет вам. Не смотря на то, что оно простое, оно очень эффективно.

Стив Круг и Якоб Нильсен учат нас: если пользователь быстро не понял, нужна ли ему информация – он уйдет. Текст будет прочитан очень бегло, буквально одно-два предложения.

Как правильно составить текст для сайта? Что поставить вперед, а что приберечь на потом? Когда я впервые задался этим вопросом, мой отец, в прошлом журналист ТАСС, рассказал о правиле пирамиды. Его, в свое время, научили коллеги из BBC (Би-би-си, а не вэ-вэ-эс, если что).

Всем привет. Cегодня я хочу рассказать вам как правильно написать статью о вашей компании в Википедии. Заодно на конкретном примере познакомлю с основными приципами и правилами.

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

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

Самым же неправильным методом переноса сайта на новый домен с минимальной потерей посетителей, на мой взгляд, будет следующий:

Доброго времени суток, Хабражитель!

Не так давно в этом же блоге Hombrelumbre опубликовал статью о своем стартапе — Хостинг Картинок.
Многие из Вас оценили его за простоту и удобство, некоторые подумали или даже сказали вслух: «Очередной заурядный хостинг картинок, только без рекламы… и то пока-что».

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

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

Итак, после недолгого обсуждения данной идеи с владельцем хостинга мы пришли к согласию и за пару-тройку выходных (и несколько бессонных ночей) не без помощи Hombrelumbre и его брата накидал дополнение к ресурсу для простой и быстрой загрузки изображений на Хостинг Картинок…

Доброго времени суток, Хабравчане. Хочу представить Вашему вниманию Хостинг Картинок.

Предыстория

Началось всё полтора года назад с симпатичного домена HostingKartinok.com приобретённого для личного использования (дабы мои скриншоты жили ровно столько, сколько мне они нужны и не были окружены «блекджеком и шл…ами» назойливой рекламой).

Если двое делают одно и то же, это не одно и то же

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

Большинство людей не могут создать расширение к Firefox — для этого нужны знания Javascript, XUL, и немного опыта в XML. Сейчас порядка 8000 разработчиков и 12000 плагинов к Firefox, но Mozilla всегда ищет пути как это расширить.

Итак Mozilla выпустила экспериментальную программу Jetpack, которая позволяет каждому, кто может создать веб страницу — создать дополнение к Firefox. Это означает, что для простого дополнения к популярному браузеру, вам нужны лишь знания HTML. Jetpack также поддерживает CSS и Javascript.

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

Jetpack очень ранний проект с открытым исходным кодом, это только 0.1 версия и там пока очень много багов. Но уже сейчас она позволяет каждому использовать API для создания статусбаров, работы с табами и многое другое. Он также поддерживает внешний API как Twitter, и вы сможете создавать простые дополнения для работы Twitter'а с Firefox.

Итак, если вы разработчик, посмотрите видеопредставление как создавать дополнения к Firefox.

Эта статья является коллекцией некоторых мощных каруселей изображений и текстовых материалов, готовых к использованию в ваших Web-проектах. Она включает в себя Agile Carousel, YUI Carousel, JCarousel, iCarousel (jQuery + MooTools) и учебное пособие о том, как реализовать простую карусель наподобие карусели во Flickr, используя Prototype-UI.

Итак, в феврале 2009 г. в языке PHP появились новые функции для работы с массивами: функции array_replace, array_walk_recursive и array_diff_assoc, что упрощает работу с массивами и сравнение их элементов.

Остановимся на каждой функции и дадим примеры их использования.

Задача:
Дизайнер нарисовал макет страницы, на заднем фоне которой была картинка. Я сначала было решил, что это фон который увеличивается по ширине в зависимости о разрешения монитора.
Но не тут то было. Дизайнер настаивал на то, что это масштабируемая картинка, которая сужается / растягивается при изменение окна приложения и по ширине и по высоте.
Заранее предупредив заказчика – что картинка будет грузиться 1 и в максимальном разрешении – его определили как 1600, приступил к работе.

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

Наибольшие трудности при построении сайтов c применением AJAX возникают при реализации механизма AHAH (Asynchronous HTML and HTTP). Особенно выполнение на лету подгружаемых Javascript-ов. Также есть куча дополнительного «гемороя» при разработке AJAX сайтов и веб-приложений. Вы можете ознакомится с детальным описанием некоторых существующих проблем. Из-за указанных сложностей, многие разработчики отказываются от более насыщенного внедрения AJAX.

Однако, мало кто знает, что перечисленные проблемы можно решить.

Обсуждение предыдущей статьи было бурным. Самые ярые любители jQuery, Mootools кричали зачем мол нужен другой велосипед.
В данной статье мы рассмотрим использование техники Fly AJAX. Это одна из нескольких функциональных возможностей, которые не реализованы в ранее указанных больших (и мною уважаемых) фреймворках. Также, в данной статье, мы рассмотрим принципы правильного проектирования и построения сайтов для хорошей индексации с применением AJAX технологии.

Сегодня мы поговорим о возможности динамической предзагрузки библиотеки по требованию. Изначально, для использования фреймворка, Вам надо на странице подключать сначала стилевой файл, потом адаптер, которые реализует основной функционал, а в случае использования другой AJAX-библиотеки в качестве основы, сначала и ее дистрибутив. И только потом уже основной файл ExtJS, либо его debug-версию на этапе разработки. Конечно, сократить время загрузки поможет объединение всех файлов в один, сжатие gzip и другие методики. Но…

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

Достоинства удаленной работы очевидны — меньше ограничений в поиске специалистов с нужной квалификацией, возможность нанимать людей за пределами МКАД, меньше расходов на ведение бизнеса. С другой стороны, есть и проблемы: наиболее значительные — со стороны организации работы. Последние 4 года я работаю тим лидом распределенной группы программистов (3-15 человек в разное время) для зарубежного заказчика, и хочу поделиться с хабрадевелоперами опытом такой работы :-)

Здесь и далее имеется ввиду следующая организация труда:

1. Заказчик (+on-site команда опционально) в офисе где-нибуть в Европе/США.
2. Тим лид распределенной команды — где-то на бескрайних просторах exUSSR.
3. Члены распределенной команды — также где-то на бескрайних просторах exUSSR.

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

Начинаю вести серию статей Это статья про вёрстку html css js, начинаю с самого простого, потом планирую описать более сложные вещи и всякие тонкости и этим видимо так и закончил