Представим, что вы владелец одной из 100500-миллионной доски объявлений по недвижимости. Вы чувствуете, что тема перспективная, бабла на рынке крутится много, вам хочется заработать и быть счастливым. Для монетизации вашего сайта у вас, допустим, есть распространённый приём: деление аккаунтов на «пользовательские» (публиковать можно только одно объявление), т.е. бесплатные, и «профессиональные», т.е. аккаунты продавцов, за деньги.

Некоторые нехорошие продавцы (поскольку они нехорошие, то будем и нехорошим словом их дальше называть — «мошенники»), в свою очередь, тоже хотят зарабатывать и не хотят вам платить.

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

Довольно давно на Хабре не было статей про такой удобный и эффективный инструмент для быстрого прототипирования как Axure RP.
Решил выложить свою подборку закладок по «Акшуре» в виде сводного списка ресурсов.

Прочитал пост про Kerning.js — небольшую js-библиотеку, можно даже сказать утилиту, для реализации чудес типографики на веб-страницах. И вспомнил, что пользовал не так давно нечто подобное — библиотеку Lettering.js.

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

Итак, Lettering.js — помощник «радикального» веб-типографа, Cryptico.js — помощник Штирлица и Rasta.js — такой простой ajax get/set помощник. Далее ссылки на сайты разработчиков этих библиотек и инструкций по их использованию.

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

Сегодня мне случилось побывать на лекции Эрика Райса (Eric Reiss), специалиста по вопросам информационной архитектуры, юзабилити и user experience.

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

Лекция была посвящена набору правил (Эрик называет их догмой), следование которым позволит создавать сайты для пользователей, свободные от диктата технологий и моды.

Вот эти 10 правил.

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

Итак, начнем. Если Вы рисуете:

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

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

ru | en, имейте ввиду, что заголовки и разделы на разных языках, имеют разное количество символов.

Поиск, то обязательно нужно отрисовать страницу вывода результатов. Так же, если вы рисуете ссылку «продвинутый поиск», то нужно показать как будет выглядеть продвинутый поиск.

Half-Life: Escape from City 17 — канадский короткометражный фанатский фильм в двух частях, действие которого происходит во вселенной Half-Life. Он был создан братьями Дэвидом и Яном Пурчейзами из Торонто, известными как Purchase Brothers. До фильма братья занимались телерекламой, в том числе сделали одну для Coca-Cola.

Первая часть «Побега из Сити-17» была выпущена 13 февраля 2009 года, а вторая вышла на днях. Братья планировали выпустить вторую часть фильма в начале-середине марта 2009 года, но большое количество писем и телефонных звонков по поводу первой части замедлили развитие второй.

Эта статья — продолжение цикла статей по информационной безопасности в веб-приложениях (и не только).

Вообще думал написать о «белом ящике», но я решил что нужно сначала ликвидировать возможные пробелы у целевой аудитории (в основном веб-разработчики) в этой области.

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

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

Как обычно — ответственность за все полученные знания только на читателе :)

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

Вкратце:

• Хотят сотрудники работать по умолчанию или нет?
• Почему авторитарные лидеры вымирают.
• Насколько важно распространение информации (менеджмент «открытых книг»).
• Кто не косячит – тот не работает.
• Как мы собеседуем.
• Как мотивировать команду.
• О рандомных премиях.
• Корпоративы: может, лучше дать всем по $100?

Есть разные методологии разработки. Каждый выбирает себе тот подход, который максимально эффективно подходит компании-разработчику. В качестве основы для собственной методологии мы используем экстремальное программирование (XP). Конечно же мы внесли в нее собственные изменения, но сегодня я бы хотел рассказать не об этом.



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

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

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

Вопросы конкурентного доступа к реляционным базам данных встают практически перед любыми разработчиками прикладного программного обеспечения и не только перед ними. Результатом такой востребованности этой области является наличие большого количества созданных архитектурных паттернов. Это позволяет успешно справляться с большой сложностью разработки таких программ. Ниже пойдёт речь о таких рецептах, а также механизмах на которых базируется их реализация. Повествование будет иллюстрироваться примерами кода на Java, но большинство материала не привязано к языку. Цель статьи — описать проблемы конкурентного доступа к реляционным базам данных, в качестве введения в предмет, а не полноценного охвата темы.

Бытует мнение, что программные системы, будучи объектом не совсем материальным, не поддаются старению. И если говорить о старении физическом, то действительно, шансы на то, что буковка “o” в имени класса вдруг от старости ссохнется и превратится в букву “c” – действительно малы. Но вместо старения физического, программные системы стареют морально.  Со временем накапливается груз ошибок за счет неточностей в исходных требованиях, непонимания требований самим заказчиком, архитектурных ошибок или неудачных компромиссных решений; да и ошибки поменьше, типа слабопонятного кода, его высокой связности, отсутствия юнит-тестов и комментариев делают свое черное дело. Все это приводит к накоплению технического долга (о котором шла речь в прошлый раз), из-за которого при добавлении новой возможности в систему приходиться платить «проценты» в виде более высокой стоимости реализации и более низкого качества получаемого результата.

По статистике, мы нанимаем одного из 10-20 обратившихся кандидатов на должность веб-разработчика. При таком потоке необходимо быстро распознавать подходящие кандидатуры. Разного рода синтетические тесты при отборе сотрудников я не люблю – бессмысленая трата времени. Лучший способ проверить – сразу кинуть в бой.

— Привет, я крутой веб-разработчик, вот мое реюзме!
— Привет, спасибо, резюме не надо, давай аккаунт на github, бери тикет No.123 и вперед! Слишком крутой для тебя? Ну выбери сам, какой тебе больше нравится, из того что есть. Другой работы нет.

Минимум затрат личного времени, максимум объективности.

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

Мы делаем это так.

Очень тяжело начать писать статью. Т.е очень тяжело придумать вступительное слово. Хочется рассказать обо всём и сразу :) Но нет. Будем последовательны.
Начну с того что совсем недавно проходил Highload++ 2008 на котором мне удалось побывать.
Скажу сразу — мероприятие было проведено по высшему клаcсу, докладов было много и все были очень интересными.
Одной из самых запомнившихся презентаций была лекция Аско Ойя об инфраструктуре серверов баз данных в Skype. Лекция в большей степени касалась различных средств с помощью которых достигается такая производительность серверов.
По словам Аско, база данных Skype выдержит даже если все жители Земли захотят подключится к скайп в один момент.

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

UPD: Как правильно заметил хабраюзер descentspb в статье присутствует досаднейшая ошибка. В следствие своей невнимательности я подумал что PgBouncer надо устанавливать между прокси и клиентом. Но, как оказалось, та проблема которую я решал с помощью PgBouncer не решится если установить его именно так. Правильнее надо устанавливать боунсер между нодами и прокси. Мало того, именно так и рекомендуется делать в оффициальном мануале на сайте PL/Proxy.
В любом случае использование PgBouncer так как указано на моей схеме также даст прирост производительности. (Разгрузит Proxy).

PhoneGap — это OpenSource платформа, позволяющая разрабатывать мобильные приложения на HTML, JavaScript и CSS под различные платформы (практически без изменения кода приложения) в их число входят: iOS, Android, Blackberry, WebOS, Symbian и Windows Mobile на подходе. Прелесть его в том, что он не требует навыков разработки под конкретную платформу. Вы пишете свое приложение на JavaScript, используете HTML и CSS для разметки. Вы пишете мобильное приложение как обычный сайт или веб-сервис.
Движок PhoneGap расширяет API браузера и добавляет следующие возможности: доступ к акселометру, доступ к камере (пока только фото), доступ к компасу, доступ к списку контактов, запись и прослушивание аудио файлов, предоставляет доступ к файловой системе, позволяет работать с разными HTML5 хранилищами localStorage, Web SQL и т.п а также позволяет безболезненно обращаться к любому кросс-доменному адресу.
Кроме платформы PhoneGap имеет, пока бесплатный, билдер приложений под все устройства в один клик.

jQuery Mobile

Думаю все знают, но напомню ещё раз. jQuery Mobile — это надстройка над jQuery, позволяющая безо всяких проблем разрабатывать мобильные веб сайты и мобильные веб приложения.

Если вы знаете HTML, JavaScript, CSS, jQuery и испытываете проблемы с Java, Objective-C и другими, но желаете попробовать свои силы в мобильной разработке, то эта статья для вас.

Опытный предприниматель Steven Blank, после того, как продал свой очередной стартап, задумался: почему 99%+ стартапов банкротятся. Посвятив несколько лет своей жизни изучению этого феномена и сравнивая со своим опытом, разработал методологию, которую назвал Customer Development. Она изложена в книге “The Four Steps to the Epiphany”. Основные постулаты методологии — строить продукт итерационно, постоянно сверяясь с рынком как можно раньше. Эта книга является настольной у большинства предпринимателей в Силиконовой Долине, а знание методологии является у многих инвесторов обязательным условием для получения раунда инвестиций. Blank читает курс на эту тему в Стенфордском Унивеситете последние 10 лет (Кстати, он подтвердил свое участие онлайн в конференции Entrepreholic и личное в IDCEE)

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

Очередной топик с обзором нескольких интересных плагинов jQuery.

Mobily Map

Позволяет сделать интерфейс, подобный google-картам, на основе собственных изображений (возможность перетаскивать, ставить маркеры на изображении, реагировать на нажатие по ним и др.).
Узнать больше (англ.) | Посмотреть в действии

Беспрецедентные объемы данных заставляют разработчиков и бизнес приглядываться к альтернативам реляционных баз данных, используемым вот уже более тридцати лет. В совокупности все эти технологии известны как «NoSQL базы данных».


Основной проблемой является то, что реляционные базы данных не могут справляться с нагрузками актуальными в наше время (мы говорим о high-load проектах). Есть три конкретные проблемных области:

• горизонтальное масштабирование при больших объемах данных, например как в случае Digg (3 терабайта для зеленых значков, отображаемых, если ваш друг сделал dugg на статье) или Facebook (50 терабайт для поиска по входящим сообщениям) или eBay (2 петабайта в целом)
• производительность каждого отдельного сервера
• не гибкий дизайн логической структуры.