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

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

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

Итак, небольшая история о том, как можно довольно легко заработать за один месяц минимум 15 000 евро.

Мой профессиональный род деятельности — веб-разработка. Занимаюсь R&D в одной небольшой IT компании, пишу «навороченные» приложения для корпоративных интранетов и, в принципе, на жизнь не жалуюсь. Конечно, при таком раскладе хочется параллельно вести какой-нибудь интересный проект, чем неоднократно занимался в мире Open Source. Со временем, правда, захотелось на побочных проектах так же как-то зарабатывать, что с Open Source оказалось не так просто, как может показаться из статей на Хабре :) Потому и решил попробовать для себя что-то принципиально новое — открыть интернет магазин.

Коллеги,

а кто как решает проблемы мультиязычности контента? с учётом SEO конечно и всех прочих рюшечек!

Мои основные постулаты это:

1) Разные языки на разных поддоменах (en.mainsite.com de.mainsite.com mainsite.com ––> default)
2) Автоматический подбор языка клиенту в первый визит (подбор либо по базе данных IP либо по языку броузера)
3) ЧПУ c спецификой языка
4) Весь контент в обной СУБД
5) Все media (картинки и прочее) живут на отдельном поддомене media.site.com
6) В шкурке языковая привязка идёт через языковой файлик (подгружается в шаблон) — из имени поддомена легко просчитать какой языкой файл использовать (кеш — уже отдельная тема, но тоже реализуется)

Я тут ебанулся на отличненько, и сделал одну очень полезную штуку, и назвал её "Gandja" (намёк не понял).

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

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

Есть проблема? Есть решение! Отчего бы не следить за изменениями автоматически (а делиться ими через SVN)? Сказано-сделано.

Welcome to Gandja. Просто и удобно. До безобразия просто и удобно.



copyright note — этот скрипт у нас быстренько на коленке набросал один дяденька, я же его причесал парочкой стилей и с общего согласия выложил на google code

Google Labs всё не перестаёт радовать «рюшечками» для GMail. Так, сегодня была анонсирована очередная приятная фишка: «canned messages», что на практике даёт собрать некий набор автоматических ответов на входящую почту. Ответы эти можно либо выбирать ручками, либо отправлять их автоматически, если входящие сообщения соответствуют заранее определённому фильтру! Ляпота :)

Уря, хабралюди, свершилось! Отныне в gmail появились расширеные настройки IMAP (для тех, кто подключился к каналу расширений Google Labs). Можно отключить синхронизацию «ненужных» папок, настроить автоочищение мусора и масса прочих приятностей. Так что активируем и радуемся!

Гугл в тёмных подвалах своих лабораторий запустил новую фишку: отныне они в состоянии распознавать речь (правда пока только на английском), что делает возможным поиск по ключевым словам в видео-файлах youtube. Новый проект носит кодовое название «GAudi», и оценить его в действии можно уже сейчас.

Странно что никто не задумывался над тем, что наличие в кармане iPhone с включеным wi-fi это практически конец конфиденциальности. Так, например, любой пользователь данного хот-спота может лёгким движением руки получить доступ ко всем вашим sms. Расскажу как это сделать:

1. Находим в сети IP адрес вашего iPhone — (для этого есть масса всевозможных сканнеров локальной сети; самые простые смертные с доступом к админ-панели домашнего рутера могут посмотреть это там)
2. Из терминала (putty для пользователей виндуфса) логинемся в iPhone жертвы: ssh root@ip-address как пароль используем слово «alpine»
3. Из папки /private/var/mobile/Library/SMS/ копируем к себе на комп файлик sms.db
4. Локально открываем этот файлик программой SQLLite Database Browser
5. Нервно хихикаем

Как защититься от ваннабихакеров? Сменить пароль рута на вашем iPhone!

Сегодня утром получил на свой @me.com ящик письмо от Apple (см. под кат) краткий смысл которого сводится к тому, что

• MobileMe приложение для веб в первые пару дней нехило косячило — их вина и недоработка
• Посколько синхронизация Mac-ов и MobileMe не мгновенная (как с iPhone), то они убрали везде с сайтов и рекламы слово «push», и реинкарнируют его лишь когда весь хардвер Apple будет синхронизироваться с MobileMe мгновенно
• Ну и в виде пряника всем подписчикам дают месяц бесплатного пользования сервисом :)

С выходом в свет Leopard 10.5.3 в адресной книге появилась возможность синхронизировать контакты с вашим аккаунтом Google! Ну разве это не прекрасненько?

Ну и что, скажите, сложного в том, чтобы вешать в своей системе на все единицы контента N тегов, и после делать по этим тегам выборку с системой релевантности и важности связей? Да ничего в этом сложного нет, ибо это типовая задачка по проектированию БД из 10го класса! Что? Вы всё ещё кипятите? Ну тогда я расставлю быстренько все галочки :)

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

О Великие Хабрасоздатели, а может быть стоит сделать дополнительную настройку для _каждого_ блога, в которой будет указан минимальный уровень кармы для постов в оный. Так, например, в некоторые блоги можно будет писать с кармой в 2-3, когда для других проходной барьер может быть больше 20ти

Порой очень интересно знать кто и за сколько денег делает Онлайн-Банкинг системы, ибо у лидирующих европейских банков это такой нереальный ацтой, что конечного доверия к ним, увы, немного. В первую очередь пугают не столько ужасные и мало-интуитивные интерфейсы, сколько отталкивает совершенно убогая система безопасноти доступа к данным и логика действия приложения.
Мне, признаться, не понятно кто дал добро лохам разрабатывать такие сложные системы. Конечно, я понимаю, что всем надо с чего-то кормиться, а потому делать «banana-software» на порядок выгоднее, чем поставлять сразу отменный и рабочий продукт, на поддержку которого у заказчика уйдёт минимум времени и ресурсов. Но, это же большие, международные банки и имидж для них должен быть всем!!!
Ладно, дабы не мутить воду вилами на пустом месте — проиллюстрирую мой тезис парой живых примеров. Для начала рассмотрим онлайн-сервисы одного из самый больших банков мира — HSBC.

Идеальный гаджет не должен иметь НИ ОДНОЙ кнопки. Так, например, я на днях купил домашнюю «погодную станцию (weather station)», она показывает практически всё, что может быть интересно простому смертному о погоде. Так же показывает дату, время, лунный цикл и прочие приятные мелочи. При всём при этом на аппарате нет НИ ОДНОЙ кнопки – вся настройка происходит автоматически.

Ну разве это не прекрасненько?

Значится так — есть задача вытянуть данные из таблицы mysql в простенький csv файлик, дабы его открыть быстренько в excel. Зачем белым людям нужна такая магия — мне никогда не понять, но раз заказчик попросил, то я сделал. Итак, отдаёмся во власть консоли и пишем:
mysqldump -u [USER_NAME] -p "--where=[WHERE]" "--fields-terminated-by=," "--tab=./" [DB_NAME] [TABLE] > [TABLE].txt

Вот и вся любовь (на выходе получим два файла — один с SQL и второй с CSV)

p.s. директория в которой выполняется эта команда должна быть открыта для записи, иначе оно ругаться будет ;)

Я полагаю что многие заметили, что на офсайте MySQL отсутствует dmg пакет MySQL для Леопарда. Рисковать и «прогонять» тигровый пакет я не стал, а просто собрал свой БД сервер прямо из исходников. Делается это примерно так:

Необходимо знать/уметь/иметь:

• Вы знаете что такое консоль и как ей пользоваться (пусть на уровне чайника – этого будет достаточно)
• Вы знакомы с основами *nix и не испытываете проблем с оргазмом от полупрозрачной консоли в MacOS X
• У вас уже есть XCode, если его нет – скачайте и установите с офсайта XCode 3.0

Итак, в дело, бейби, да!

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

В итоге на сайтах из серии odnoklassniki.ru или vkontakte.ru заметный процент пользователей указывает свои имена/фамилии латинницей. Отсюда следует, что найти их через форму поиска становится достаточно сложно, ибо приходится после поиска кириллического имени фигачить все возможные варианты транслита.

После небольшого апокалипсиса сервиса afraid.org, а несколько позже и многочасовой недоступности xname.org — Пользователям бесплатных DNS посвящается: «Как выжить в этом мире и обезопасить от провала ваши домены!»

Итак, всё очень просто, ибо исходим мы из соображения, что вероятность того, что полностью в один момент свалятся два сервиса — ничтожно мала. А потому, вместо того, чтобы хостить свои NS записи у одного провайдера (будь то xname.org или afraid.org), мы делаем один из них primary DNS а второй назначаем как secondary.

Например, домен essentialmind.com имеет три NS записи: две указывают на xname.org и одна на afraid.org. На сервисе afraid.org домен внесён в реестр как «secondary», а потому автоматим синхронится с «primary» записями на xname.org. В итоге имеем довольно устойчивую и, что немаловажно, быструю систему нейм серверов.

Nota Bene: Вообще-то, в RFC написано, что DNS сервера должно быть как минимум два и они должны находиться в разных сетях класса «С». Что на практике 30 лет назад означало «в разных городах»; сегодня же реальность такова, что разные адреса сетей класса «С» могут легко находиться в одном пыльном подвале. Что и ведёт к перебоям сервисов подобным xname и afraid

Да-да, все «реальные пацаны» умеют строить веб-системы, способные выдержать монументальные нагрузки. Ну а для «непацанофф» всегда есть гугл и масса сайтов посвящёных данной тематике. Однако «проблема роста» включает в себя не только вопрос верной сервировки данных клиенту и их грамотной репликации/распределении на кластере. Зачастую проблемы возникают от того, что всё как раз-таки наоборот — слишком шустро работает. Рассмотрим пример из недавней практики: