Совсем недавно в авторитетном журнале Wired была опубликована интереснейшая статья «In the Next Industrial Revolution, Atoms Are the New Bits», описывающая революционные процессы, происходящие в настоящее время в промышленности, сходные с теми, которые происходили в Интернет. Ниже приводится перевод первой части статьи.

Дверь, похожая на вход в прачечную, в индустриальном парке Ворхема, штат Массачусетс, не очень-то и напоминает ворота в будущее американского машиностроения, но на самом деле таковым является. Это штаб квартира Local Motors, первой open source компании, которая производит автомобили. Стоит только зайти внутрь и мы увидим шокирующий пример того, что можно делать на микрозаводах.

Сколько процентов пользователей вашего сайта являются также пользователями ВКонтакте? Как по вашему, сколько человек ничего не пишут / комментируют / добавляют (нужное подчеркнуть), лишь потому, что им лень регистрироваться на еще одном непонятном сайте в 100й раз? Предлагаю ответить для себя на эти 2 вопроса, прежде, чем ругать ВКонтакте и Open API.

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

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

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

Элементы в исходном коде

— доступ к сетевым ресурсам
— обработка xml
— доступ к файловой системе
— работа с потоками

Я делаю шаблоны на чистом HTML/CSS уже больше восьми лет. За это время я убедился, что различные соглашения и документирование помогают в работе. Конечно, они не спасают от периодических CSS-кошмаров. Они лишь делают их менее болезненными. Мое решение — следовать определенным принципам в написании стилей. Эти принципы образуют основание, на котором будет строиться все дальнейшее написание стилей, облегчая работу над растущим проектом.

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

Мы две недели проектировали и создавали приложение для iPhone. Я послал письмо маме с названием программы и одной строчкой описания этого приложения. Она ответила одной фразой: «Я не понимаю». Мы выбросили исходники и саму программу и начали сначала.

Наиболее важный урок, который мы получили работая с App Store — большинство неудачливых разработчиков App Store все еще не поняли: если по названию и короткому описанию мама сразу понимает что это, программа будет продаваться более чем в 30 экземпляров в день. Если из названия и описания мама не понимает о чем идет речь, программа будет продаваться менее 5 экземпляров в день. К сожалению, другие разработчики App Store не имеют доступа к моей маме или ее вкусным рогаликам, поэтому мы будем и впредь сохранять это стратегическое преимущество.

Основная причина успеха программы: Убедитесь, чтобы описание вашей программы было предельно понятно. Если это не так, то упростите.

Мы обещали держать вас в курсе новостей по «Чип энд Дэйли». Я расскажу об итогах за 3 месяца – финансовые итоги (оборот, маржа), почему 1 млн. пользователей во Вконтакте бесполезны для бизнеса, откуда не брать трафик. И о нашем новом проекте DarBerry.Ru

Недавно я наткнулся на сайт Dragon Interactive (dragoninteractive.com). Сайт этот достаточно добротно сделан в плане дизайна. А изюминкой можно назвать их анимированное меню. Ну вот если бы это было сделано в Adobe Flash, я даже и не упоминал бы о таком. Но при более близком рассмотрении оказалось, что их меню — это сочетание простых XHTML, CSS и Javascript. В данной статье я собираюсь продемонстрировать, как создавать менюшки (очень близкие к Dragon Interactive’s menu).

Смотрим демо

Продолжаем идею антианалогов.

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



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

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

UPD: Baseline такой: раз сноски всё равно читают, то почему бы не перенести их поближе к основному месту действия.

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

«Сноска — помещаемые внизу страницы примечание, библиографическая ссылка, перевод иноязычного текста, связанное с основным текстом знаком сноски».

Классическая реализация в отечественной традиции:

Что с ними «не так»?

Отвлечение от основного текста замедляет чтение,

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

Amy Editor

Созданый в 2007 Петром Кронторадом (Petr Krontorad), Amy Editor продвинутый редактор с интерфейсом в стиле Mac. Amy Editor имеет в наличие кучу полезных опций, такие как нумерация строк, подсветка синтаксиса, сниппеты для более чем 20 языков, совместное использование и прочее.

» http://www.amyeditor.com

Пока все Интернет сообщество со всех сторон продолжает обсуждать, как же можно приспособить iPad для работы, я бы хотел все же вернуться к iPhone. По профессии я программист и люблю новые технологии. И очень мне уж хотелось сделать приложение для своего телефона, но вот как-то душа к Objective C не лежит пока что, да и макбука с лицензией разработчика тоже пока нет. И мне стало интересно, могу ли используя знания html и js написать что-нибудь. Оказалось что да, и способов очень даже много. О них – под катом.

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

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

Мы писали о jQTouch, основанном на jQuery iUI-подобном наборе средств, созданном Давидом Канедою (David Kaneda).

Сегодня они выпустили новую версию, которая улучшает их расширяемую систему нижеследующим:

• Улучшенный переход к 3D-перевороту (improved 3D flip transition)
• События обратного вызова (callback events) для всех переходов между страницами, сильных тычков (swipe events), изменений ориентации
• Прилагаются демонстрации: Часы, To-do, Главное функциональное демо
• Темы: в настоящее время есть темы Apple и jQTouch (серого цвета)

Читайте далее о том, как начать действовать, и об API обратного вызова.

Это статья о работе фрилансеров. Сам я много раз выступал как в роли заказчика, так и в роли исполнителя работ; наш аккаунт на free-lance.ru занимает 5 место в рубрике "сайты под ключ", хотя ему всего 9 месяцев (пока писал, сместился на 6-ое место).
Хочу поделиться с вами некоторыми соображениями об успешном фрилансе.

1. Правильное взаимодействие с заказчиком – половина успеха.

Грамотное общение с заказчиком – это половина успеха проекта. Помните, недостаточно быть хорошим программистом или дизайнером, чтобы быть успешным фрилансером. Вы еще и менеджер. Много зависит от того, как вы сумеете продать свои услуги, как будете общаться с заказчиком в процессе выполнения работы.
Заказчика в основном интересуют три вещи: адекватность исполнителя, его опыт (портфолио) и цена. Чуть менее – сроки работ.
Показать то, что вы вполне адекватный человек, с которым можно работать – это самое легкое из этого списка. О некоторых простых вещах при общении многие фрилансеры забывают. Не выставляйте заказчика дураком, даже если он действительно совершенно не разбирается в вопросе. Не дайте почувствовать ему себя ламером. Объясните ему суть вопроса без использования узкопрофессиональных терминов, посоветуйте лучший вариант реализации. При общении не используйте сленг, обращайтесь к заказчику на «вы», пишите без грамматических ошибок. Особенно актуально, когда вы говорите с потенциальным клиентом — вы ничего о нем не знаете. Может он старше вас в два раза и обращение «привет» его коробит.

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

Каждый заказчик хочет заплатить поменьше, получить побольше. Это нормальное желание каждого клиента и покупателя. Но все имеет свою стоимость. И не каждый это понимает, пытаясь сильно сбить цену. Держите свою планку. Можно сделать небольшую скидку, но если заказчик хочет сбросить цену вдвое – значит, это просто не ваш клиент. Цените свой труд. У заказчика может быть масса надуманных причин, с помощью которых он станет просить изменить цену. Самые популярные:
Сейчас я у меня только эти деньги на проект, но в будущем у меня будет много денежных заказов для вас. Когда-нибудь, может быть. Это не повод снижать цену.
Давайте вы поработаете за % от прибыли будущего проекта. А заказчик тогда вообще зачем нужен?
Мой начальник выделил определенный бюджет, я бы рад заплатить больше, но не могу. Практически любой бюджет можно пересмотреть. Нет? Но тогда это проблема заказчика.
А у Васи Пупкина дешевле. Что же вы тогда не заказываете у него?

Немного воды
Разрешите представиться — фрилансер-дизайнер с опытом работы чистым фрилансером всего полтора месяца.
Профессиональный опыт работы в вебе — более 6 лет. Именно эти шесть лет позволили мне сейчас стать тем, кем являюсь и окончательно выбрать вектор своего движения.

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

Но, как оказалось, я ошибался. Потому-то как минимум 50% фрилансеров просто не понимают каких-то прописных истин, о которых я и хочу поведать далее.

10 слов об идее.

GTD планировщик в виде многопользовательской RPG для команд разработчиков, вот.

Коротко.

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

Lol, это шутка? Да, так и есть, это шутка. Но в каждой шутке, как говорится, есть доля шутки.

…Говоря о лени и ММО, сейчас я задумываюсь, если мне так влом утром вставать на работу, если мне так лень было ходить на пары, если мне нужно огромное количество усилий потратить, чтобы заставить себя наконец открыть Flex Builder и дописать этот глупый проект, почему я 4 месяца не получая за это зарплаты, вставал в 6 часов утра и весь день «работал» в игре? …

Дла заинтересовавшихся или тех, кому просто любопытно — велкам за хабракат. А вот пока картинка на затравку.

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

Присказка

Написать пост меня побудило вчерашнее осознание того, что нанятый мной флешер оказался таким же кретином, как и двое предыдущих. Задача состояла в том чтобы написать приложение для ВКонтакте на базе недавно анонсированного ЧатВдвоем. Казалось бы, простое дело, так как есть очень строгое ТЗ, детально описывающее все нюансы протокола. Тем не менее, первый нанятый флешер спустя четыре(!) недели сказал:

Нужна реальная причина? Сейчас я сбросил все проекты, т.к. переживаю кое-какой период

Второй флешер, спустя три недели:

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

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

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

Недавно на Хабре была опубликована статья под провокационным заголовком и призывом к прекращению изобретений велосипедов в API-строении. Поскольку тема мне интересна, то я просто не мог пройти мимо.
Увы, реальность за хабракатом меня сильно разочаровала — я увидел очередной велосипед, да еще и с квадратными колесами. (Коллеги, ничего личного, только техническое обсуждение.) Правда, авторы честно сказали, что увидели на нескольких сайтах модное слово REST и решили сделать по нему. Только вот поняли они этот «РЭСТ» по-своему, примерно как Дед Щукарь читал и понимал толковый словарь.
В этом топике я призываю по-настоящему покончить с велосипедами в API сайтов. Ведь получается какой анекдот: АПИ разрабатывается для упрощения доступа к сайту и легкости подключения внешних систем, а получается такой, что с ним еще сложнее, чем без него :)

Чуть ниже под катом я подпишу смертный приговор всем велосипедам в универсальных API. Чтобы не быть голословным, я все проиллюстрирую примерами.
Но должен предупредить сразу — после прочтения статьи вы не сможете без рвотного рефлекса смотреть на очередной велосипед Васи Пупкина под гордым названием «универсальное API сайта».

В повествовании будут рассмотрены следующие вопросы:

1. Базовые технологии: XML-RPC, REST, SOAP и краткое сравнение
2. Дао вебсервиса
3. Просветленные API
4. Как отличить сайтовое API от говна
5. Выводы