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

Итак, три самые ненавистные вещи для пользователей: изменения, неожиданности, разрыв контекста.

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

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

Изменения

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

По западной статистике двухлетней давности, 4,7% пользователей выбирают в качестве пароля слово “password”, 8,5% — “password” или “123456”, 10 самых популярных паролей покрывают 14% всей пользовательской базы (40% — топ-100, 79% — топ-500, 91% — топ-1000).

При создании сайта было бы вполне логично составить список общеупотребительных паролей и запретить их при регистрации пользователя. Казалось бы, вполне логичная идея, но… к сожалению, процесс аутентификации в ИТ покрывается множеством патентов, пишет консультант по ИТ-безопасности Марк Бернетт (Mark Burnett). Они описывают самые очевидные, общеизвестные и обыденные техники. Похоже, абсолютно все возможные аспекты выбора пароля, процесса аутентификации, хранения и восстановления информации защищены одним или несколькими патентами.

Статистика для инди разработчика

Автор Emeric Thoa

Перевод мой

Intro

Когда я распрощался с работой на крупную игровую компанию и основал свою игровую студию, было интересно прикинуть, сколько денег можно было ожидать заработать как инди разработчик. Проработав в Ubisoft в разработке консольных AAA игр, у меня были некоторые соображения. Но они для моей новой инди жизни уже были неактуальны. 20-ти миллионные бюджеты в долларах, команды из 20 тысяч человек, продажи по 70 долларов за копию… Я понимал, что для инди все намного по-другому, но информации о том, насколько по-другому было очень недостаточно.

Angry Birds взлетела на Олимп, Plants vs. Zombies уже была показательным образцом успеха, Doodle Jump был хорошим примером успеха в то время, когда я стартовал, Cut the Rope продавалась по миллиону копий в неделю. Но, кроме случаев, которые я называю джекпотами, в сети было очень мало публичных данных со статистикой. Это значило, что финансовые ожидания от первого проекта SQUIDS были покрыты мраком необоснованных предположений. С тех пор, я собираю статистику и в этой статье хочу поделиться информацией с собратьями по оружию – инди разработчиками, которые находятся на той стадии, на которой я сам был полтора года назад.

Мифы App Store

Я предоставлю пост-мортемы и статистику, характерную для индустрии, и обосную какое место занимает наш проект SQUIDS в общей картине. Но, сначала я развенчаю несколько мифов про App Store с точки зрения денег.

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

Cписок будет полезен всем, кто занимается созданием новых фич, новых продуктов – продакт-менеджерам, стартаперам и прочим людям созидательных профессий.



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

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

В статье будет рассказано о базовых подходах к возврату асинхронных результатов, функциях обратного вызова, объектах deferred и их возможностях. Будут приведены примеры на языке JavaScript, а также произведён разбор типового объекта deferred. Статья будет полезна программистам, начинающим постигать асинхронное программирование, а также знакомым с ним, но не владеющим объектом deferred.

Для начала, ликбез и несколько фактов:

• ECMAScript — это официальный стандарт языка JavaScript (Слово JavaScript не могло быть использовано, потому что слово Java являлось торговой маркой компании Sun) Т.е. JavaScript — это имплементация стандарта ECMAScript.
• TC39 — комитет, развивающий стандарт ECMAScript и принимающий решения по включению фич в него.
• ECMAScript стандартов много. Самый популярный из них — ECMA-262.
• ECMAScript 5 — последняя редакция стандарта ECMA-262 (утвержден в 2009 году).
• Предыдущие версии стандарта ECMA-262 были (совсем старые не упоминаю):
  
  • ECMAScript 3 — поддерживается большинством браузеров (утвержден в 1999 году).
  • ECMAScript 4 — не принят в виду слишком радикальных изменений в стандарте. Позднее в июле 2008 году в урезанном варианте (но все же намного богаче, чем ECMAScript 3) вылился в новый проект ECMAScript Harmony.
  
  
• ECMAScript 6 (кодовое имя ECMAScript.next) должен утвердиться до конца 2013 года.

Итак, что же нас ждет в новой версии JavaScript?

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

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

Здравствуйте!

Я — Фёдор furikuretsu Ананьев, веб-разработчик студии Hot Dot, и сегодня я дам несколько простых советов для тех, кто хочет сделать своё JS-параллакс-приложение очень и очень быстрым.

В расширениях Хрома принято указывать версию скрипта в виде не более чем 4 чисел, разделённых точками, и величиной не более 32767 каждое и не начинающихся с цифры 0. Этого более чем достаточно, если в номер версии включены обычные данные: версия, подверсия, сборка. Если в версию хотим поместить дату в виде 3 чисел, то в наиболее удобной для чтения записи (версия.год.месяц.день) числа года, месяца и дня занимают 3 места из 4. На версию остаётся первое число (как более приоритетное перед датой), а на подверсию и минор ничего не остаётся. Задача: как расположить минорную версию, чтобы уложиться в формат, чтобы дата была читаемой, а версия с минором при сравнении 2 строк занимала правильное место в ряду версий? Кроме того, нужна процедура выделения даты и версии с минором из общей строки.

Всем привет!

Сегодня поговорим на тему как «профессионально сэкономить» деньги при использовании облачных сервисов Amazon Web Services при размещении веб-решений, адаптированных для России. Мы активно используем сервисы данного облачного провайдера для проектов компании почти 2 года и постоянно занимаемся оптимизацией расходов. Довольно странно, что важная тема оптимизации расходов на Amazon Web Services, очищенная от маркетингового булшита, как-то не особо представлена в сети. Постараюсь предметно поделиться опытом и обозначить явные выгоды и ошибки, которые следует учесть при проектировании веб-систем.

Просматривая одно из обучающих видео "Школы разработки интерфейсов" Яндекса, наткнулся на ссылку на офигенный труд израильской веб-программистки Тали Гарсиэль (Tali Garsiel) "How browsers work" (Как работают браузеры).

Она в течение нескольких лет отслеживала всю издаваемую информацию о внутреннем устройстве браузеров, изучала исходный код WebKit и Gecko и, в конце концов, собрала все воедино. Вот что пишет сама Тали:

Когда на 90% компьютеров был установлен IE, приходилось мириться с тем, что это загадочный «черный ящик», однако теперь, когда более половины пользователей выбирает браузеры с открытым исходным кодом, пришло время разобраться, что скрывается у них внутри, в миллионах строк программного кода на C++...

Пролистав, я был поражен — отличная работа. Внутреннее устройство браузеров, алгоритмы разбора — все хорошо иллюстрировано, доступно и понятно. И без излишних подробностей, страниц на 30-40. Как раз то, что нужно. Решил — это надо обязательно перевести. Покопался еще немного — оказалось перевод уже как 1,5 года есть!

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

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

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

По данным w3techs на 19 марта 2013 г., русский язык обошёл немецкий и стал вторым по распространённости языком веба.



Русский язык используют 5,9% всех сайтов Интернета.

Жизнь – как вождение велосипеда. Чтобы сохранить равновесие, ты должен двигаться.
А.Эйнштейн

Преамбула: в Alconost мы делаем продающие видеоролики для программных продуктов, веб сайтов, онлайн сервисов, мобильных приложений. Ключевая роль в таких роликах отводится скринкастам — показу действий пользователя в программе/сервисе/на сайте. Скринкаст — это показ товара “лицом”. Если скринкаст сделан убого — у зрителя останется ощущение убогого продукта и задача “мотивировать попробовать продукт” будет провалена.

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

Итак, если вы заказали видеоролик, и вам раз за разом присылают промежуточные версии с отстойными скринкастами — покажите вашим «видеоменам» вот этот ролик:



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

Началось все примерно 4 года назад, в феврале 2009 года. Тогда мы с моим будущим партнером Сергеем работали в компании производителе электроники в Южной Корее. Оба были полны желания что-нибудь сделать, и располагали достаточным количеством свободного времени. Сергей работал девелопером, а я занимался логистикой…

Это четвертая часть, она же заключительная, перевода статьи Пола Грэма, основателя YCombinator — одного из самых успешых стартап акселераторов -, о том, как найти свою идею для стартапа. Первая, вторая и третья части по ссылке.
Так же хочу скромно анонсировать свой небольшой некоммерческий проект — 42Startups.ru,- блог, где вы можете найти другие переведенные с английского языка статьи о стартапах. Лучшие, из тех, что мне попадаются и которые, на мой взгляд, достойны внимания русскоязычной аудитории. Подписывайтесь! А пока продолжим:

Рецепты

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

Остаток эссе я посвящу уловкам, которые помогают найти стартап-идею по требованию.

Продолжение статьи Пола Грема о поиске идеи для стартапа. Первая и вторая части тут. Без лишних слов продолжаем:

Университет

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

Данный пост является продолжением первой части перевода одной большой статьи Пола Грэма о том, как найти свою стартап-идею. Это не пошаговая инструкция, а скорее глубокое философское эссе Грема, основанное на его богатом опыте в качестве основателя YCombinator — самом успешном стартап-акселераторе. Продолжаем:

Сознание

Но как определить, есть ли путь «наружу» у идеи? Как понять, является ли это зачатком большой компании или всего лишь продуктом, обреченным на узкую нишу? Часто это не возможно сделать. Фаундеры AirBnb не осознавали в начале, на рынок какого масштаба они покусились. Изначально у них была более узкая идея. Они собирались позволить владельцам сдавать свое пространство во время выставок, конференций. Они не предвидели экспансию этой идеи; она сама себя навязывала постепенно. Все что они знали в начале, что на крючке какая-то рыба. Возможно, это столько же, сколько знали изначально Билл Гейтс и Марк Цукерберг.

Недавно вышла статья Пола Грэма о поиске идеи для стартапа. Грем — сам по себе культовая личность Кремниевой долины и уже только поэтому достоин внимания. Но на мой взгляд, эта статья одна из лучших в своем роде. Да, о Customer Development и Lean Startup сейчас не пишет разве что ленивый, но она отличается глубокой внутренней философией Грема и обобщает его богатый опыт в качестве основателя YCombinator, общающегося с тысячами стартаперов в год.
Статья очень длинная, поэтому я взял на себя смелость разбить ее на 5 частей, дабы никого не утомить. Поехали:

Лучший способ найти идею для стартапа — не думать о ней. Найдите проблему, и лучше — если она есть у вас самого.

Весной 2012 г., Питер Тиль (Peter Thiel), один из основателей PayPal и первый инвестор FaceBook, провел курс в Стенфорде — «Стартап». Перед началом Тиль заявил: «Если я сделаю свою работу правильно, это будет последний предмет, который вам придется изучать».

Один из студентов лекции записывал и выложил транскипт. В данном хабратопике astropilot переводит двенадцатое занятие.

Занятие 1: Вызов будущего
Занятие 2: Снова как в 1999?
Занятие 3: Системы ценностей
Занятие 4: Преимущество последнего хода
Занятие 5: Механика мафии
Занятие 6: Закон Тиля
Занятие 7: Следуйте за деньгами
Занятие 8: Презентация идеи (питч)
Занятие 9: Все готово, а придут ли они?
Занятие 10: После Web 2.0
Занятие 11: Секреты
Занятие 12: Война и мир
Занятие 13: Вы — не лотерейный билет
Занятие 14: Экология как мировоззрение
Занятие 15: Назад в будущее
Занятие 16: Разбираясь в себе
Занятие 17: Глубокие мысли
Занятие 18: Основатель — жертва или бог
Занятие 19: Стагнация или сингулярность?