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



Поэтому CMS Magazine и Nimax проводят исследование. Мы хотим собрать исчерпывающий список программных продуктов, которые помогают организовывать работу компании веб-разработчика.

Прим. переводчика — В оригинале использовался всем знакомый термин «software engineer». Так как русский его аналог «инженер-программист» используется в повседневной речи редко, пришлось использовать слово «разработчик» как наиболее близкое. Также профессия «short-order cook», с которой автор сравнивает положение многих разработчиков в индустрии, была переведена как «мальчик на побегушках» — мне кажется, что она отлично отражает суть проблемы отношения к разработчикам. Наконец, я старался везде вместо слов «to code» и «programming» использовать «разрабатывать» и «разработка» из-за сложившемся в русском языке негативном смысле слов «кодировать» и «программирование» как примитивных процессов перевода требований в машинные инструкции низкого или высокого уровня.

Автор оригинальной статьи — Nickolas C. Zakas, известный фронтенд разработчик и JavaScript-евангелист в свое время проработавший более пяти лет в Yahoo. Это запись из его блога, в которой он говорит о том, почему с разработчиками так сложно договориться и что с этим делать.

Не так давно Дженна Байлотта написала замечательную статью «Как дизайнерам ужиться с разработчиками», в которой она описывает методы работы в команде, позволяющие дизайнерам и разработчикам добиться лучшей производительности. Я в свое время работал с дизайнерами (а, работая в UI, и с разработчиками) и столкнулся с похожими проблемами, так что мне понятен ее практичный подход. Во время командной работы никогда не помешает уважать труд своих коллег и понимать их способ мышления.

Одна из главных мыслей той статьи заключалась в том, что разработчики говорят «нет» слишком быстро. Эта мысль тут же въелась мне в мозг и долго отказывалась вылезать оттуда. Мне хотелось воскликнуть: «Но подожди, ты же не понимаешь, почему мы говорим „нет“!». Тут же появился миллион других защитных аргументов. На самом деле она, конечно, права — мы правда слишком быстро говорим «нет», причем не только дизайнерам, а вообще всем. Это побудило меня поразмыслить над психологией разработчиков и тем, что составляет нашу истинную суть.

Приятного времени суток!

Сколько человек хочет заняться разработкой под Android, но в силу определенных обстоятельств все никак не может начать (у кого-то нет времени, кому-то скучно просто прорешивать примеры, лень, неопределенность)? Сколько человек добавляет каждую, кажущуюся интересной и полезной, статью на хабре в избранное и забивает? До конкурса ВКонтакте на разработку мессенджера под Android, я был среди числа вышеописанных пользователей. Но в один роковой момент все изменилось…

Это перевод оригинальной статьи Principles of User Interface Design

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

— Пол Рэнд (Paul Rand)

1. Обязанность интерфейса — обеспечение взаимодействия

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

По работе мне периодически приходится визуализировать численные данные — в виде таблиц, диаграмм или графиков. Из последнего прочитанного по теме наиболее интересной показалась известная книга Тафти The Visual Display of Quantitative Information. Я решил сделать из неё краткие выписки по относящимся к моим задачам вопросам. Ключевое слово здесь — краткие. Максимум полезной информации на минимум текста (даже стиль изложения будет подчёркнуто лапидарным). Дополнительные сведения и собственные мысли буду скрывать под спойлер. Надеюсь, мой конспект будет полезен хабрасообществу; предлагаю также поделиться своими наработками и полезными ссылками.

На днях команда HTML5-карт Nokia предоставила API карт под смартфоны и планшетники.

С места — в карьер!

Попробовать можно по ссылке: bit.ly/html5map
На данный момент поддерживаются Webkit-браузеры.

Достоинства и возможности

• Компоненты
  Карты, пробки, поиск, геолокация, информация об интересных местах, навигация, пешеходные маршруты, избранное.
• Вес
  80 KB Javascript + 10 KB CSS
• Производительность
  Быстрая загрузка и плавные эффекты.
• Готовность
  Можно легко поменять цвета, обернуть в PhoneGap или QtWebkit и получить готовое приложение.
• WYSIWYG-помощник
  Помогает настроить конфигурацию под себя.

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

В этой статье я хочу рассказать об элементах продающего дизайна для сайта. AIDA — (Attention, Interest, Desire, Action — внимание, интерес, желание, действие) — принятая в практике американского маркетинга модель потребительского поведения, описывающая последовательность событий, ведущих к принятию решения о покупке: внимание → интерес → потребность → действие.

Принципы AIDA главным образом относятся к дизайну целевых страниц (landing pages), где, как правило, маркетинг и веб дизайн объединяются в единое целое. Эти страницы нацелены на продажу продукта, услуги или подписки.

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

Но есть очень важный момент – мы не можем круглосуточно быть привязаны к рабочему месту и этим мониторам. Мы динамичны. Бизнес должен идти за нами и ни в коем случае не должен отставать. Мы не должны терять драгоценные часы или дни для принятия тактических решений, где бы мы не находились: на улице, под землей, в небе или на воде.

Одна из главных особенностей App Store — он пробуждает в дизайнерах креативное мышление. Кажется, будто каждую неделю появляются отличные идеи для интерфейсов, что очень радует все коммьюнити.

Один из подразделов мобильного дизайна — дизайн иконки в App Store. Он, похоже, превратился в отдельную форму искусства. Очень талантливые художники находят все более и более интересные способы, чтобы продемонстрировать приложение в небольшом пространстве.

От переводчика: примеры красивых иконок и еще немного текста под катом.

На презентации Adobe CS6 в Самаре я делал доклад о том как мы в компании Parcsis используем Adobe Illustrator для создания веб- и мобильных интерфейсов. Хочу поделиться этим докладом с вами в виде слайдов с комментариями.



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

В первой части статьи я кратко описал принципы RESTful и объяснил каким образом следует проектировать архитектуру вашего сервера так, чтобы можно было легко выпускать новые и прекращать поддержку устаревших версий вашего API. В этой части я кратко расскажу о HATEOAS и Hypermedia, а затем расскажу о роли, которую они могут сыграть при разработке нативных приложений для мобильных устройств. Но главной темой этой статьи будет реализация кэширования (точнее поддержка кэширования на стороне сервера). Целевая аудитория включает разработчиков серверного ПО и, в какой то мере, разработчиков под iOS или под другие мобильные платформы.

Вместо вступления

Всем доброго времени суток!

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

К сожалению, одного только CSS частенько не достаточно, чтобы с легкостью оформить тот или иной элемент формы. Наверное поэтому многие используют штуки вроде Uniform для своих форм. Лично я всегда стараюсь сократить количество Javascript, используемого в подобных целях, поэтому хочу рассказать о совершенно нативном HTML+CSS методе кастомизации радио-кнопок и чекбоксов.

Уверен, что на большая часть специалистов на Хабре, применяют схожие методы, для тех же, кто использует js-библиотеки, вроде Uniform, надеюсь будет полезной эта статья.

Поехали!

Итак, сразу поставим цель: оформить чекбоксы и радио-кнопки, чтобы внешне они были похожи на js-магию Uniform, но сделать это максимально простым, нативным по отношению в HTML и CSS способом, а также избежать применения лишних тегов, сохраняя семантику. Как-то так.

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

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

В 2007-м Стив Джобс представил iPhone, который произвел революцию в высокотехнологичной индустрии и изменил наш подход к работе и ведению бизнеса. Сейчас 2012-й и все больше и больше сайтов предлагают нативные iOS и Android клиенты для своих сервисов. Между тем не все стартапы обладают финансами для разработки приложений в дополнение к основному продукту. Для увеличения популярности своего продукта эти компании предлагают открытые API, которыми могут воспользоваться сторонние разработчики. Пожалуй Twitter был первым в этой сфере и теперь число компаний, последовавших этой стратегии, растет стремительно. Это действительно отличный способ создать привлекательную экосистему вокруг своего продукта.

Добрый день, Хабровчане!

В продолжение статьи о нашей платформе — QuickBlox — backend для мобильных приложений я хотел бы уделить внимание на инструменты для разработки, которые доступны для скачивания.

Статья и идея написания её тут преследуют цель приведения на проект как можно большего количества бета-тестеров — реальных программистов, которые смогут дать толковые рекомендации по функционалу, а так же помочь нашему отделу QA отловить баги.

Хочу напомнить, что на данном этапе использование QuickBlox абсолютно бесплатное, и в будущем бета-разработчики смогут учавствовать в дискотных программах и сполна прочувтсвовать благодарность команды QuickBlox за сотрудничество.

Здравствуйте, Хабраюзеры!

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

8 июня на конференции mobile developer day #moco я буду рассказывать о нас и хотел бы, чтоб те, кто будут присутствовать, уже имели представление о нашем продукте.

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

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

По REST API доступны следующие модули проекта:

• Users
• Ratings
• Content
• Chat
• Messages
• Location

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

В конце апреля я делал доклад на РИФ 2012 про этапы проектирования пользовательского интерфейса. Так как видео нет, попробую представить доклад в виде слайдов с моими комментариями.



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

Введение

Коллеги, при разработке приложений, мы каждый день сталкиваемся с потребностью в гибком хранении информации (обновлении, поиске по ней, и т.д.). Класс продуктов, которые решают этот круг задач, как все мы знаем — Базы данных. Но что это такое в нашем понимании? У многих «база данных» твердо ассоциируется с MySQL, таблицами и SQL-запросами. И это устраивает до определенного момента. Действительно, реляционные базы данных дают массу преимуществ в работе: поскольку данные имеют сильную связанность, не нужно контролировать целостность базы данных. Используя простой под-запрос можно выбрать количество комментариев к каждому посту в блоге. Используя JOIN нетрудно делать сложные связанные выборки и получать данные сразу о нескольких сущностях.