Перевод статьи Джейсона Калаканиса (jasonnation.com) «How to deal with bubbles».

За свою карьеру я промахнулся более 9 тысяч раз. Проиграл практически 300 игр. 26 раз мне доверяли сделать решающий бросок, но я промахивался. В своей жизни, я терпел неудачу снова и снова. Поэтому я и добился успеха.
Майкл Джордан jc.is/bI33SE

«Мыльный пузырь интернета скоро лопнет? Когда?»
«Мне лучше продать компанию сейчас, либо подождать, и продать дороже в следующем году?»
«Нужно ли мне поднимать деньги сейчас, до того, как бум закончится?»

Мне постоянно задают эти вопросы. Раньше они не давали мне спать. Теперь же они настолько врезались в мой мозг, что превратились в инстинкт.
Молодые игроки в покер задумываются о том, как разыграть короля-девятку и восьмерку-пятерку до флопа. Так же и новоиспеченные предприниматели думают о том, как играть на рынке.
Ответ в том, что не стоит разыгрывать ни одну из рук. Также и на рынке.

В этом письме я затрону следующие темы:

1. Как я научился по-сложному (aka мой смешанный опыт)
2. Правда о пузырях
3. Правда о выдающихся компаниях
4. Что делать, если мыльный пузырь растет
5. Что делать, если мыльный пузырь лопается
6. Заключительные мысли: Как я научился всему этому (aka у кого я все это украл)

Предисловие

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

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

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

1. Будьте самостоятельными

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

В вашей системе время играет важную роль? Ваши пользователи/компоненты распределены по территории всего земного шара, или хотя бы нашей необъятной родины? Значит, вам нужны часовые пояса. Что ж, это просто. Самое сложное, что вам придется сделать — не запутаться. Об этом мы с вами и поговорим. Для начала вам нужно научиться правильно думать. Думая правильно, все остальное будет для вас либо самоочевидным, либо достаточно простым.

Начнем с часов. Все мы привыкли определять время, глядя на часы на стене. При работе с часовыми поясами такое время называется Wall clock time. В принципе, ничего плохого в нем нет, только в разных местах земного шара в один и тот же момент времени часы показывают разное время. Если задаться целью, можно придумать алгоритм перевода wall clock time одного часового пояса в wall clock time другого. Обычно надо прибавить/отнять разницу в часах между часовыми поясами, кроме (внимание) моментов перехода на летнее/зимнее время. Вот когда начинается переход, вычисления становятся по-настоящему сложными.

Нам же нужно что-то простое и пуленепробиваемое, как… целое число.

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

Однако первоначальный опыт и навыки управления компанией приобретать где-то нужно, причем желательно, чтобы без плачевных последствий. Одним из таких вариантов, так сказать, для «тренировки на кошках» является использование какого-либо бизнес симулятора. В данном топике хотелось бы кратко рассказать об одном из самых популярных бизнес симуляторов — симулятор на проекте Global Management Challenge, в котором нам удалось поучаствовать.



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

Предисловие

Столкнулся с насущной проблемой, которая автоматически становится задачей:
Как реализовать универсальный механизм перевода контента сайта, который удовлетворял бы потребности как маленьких сайтов, так и больших порталов?


Хотелось бы услышать мнение компетентных хабрапользователей, которые сталкивались с данной или подобной задачей.

Смешно слышать, как кто-то так сильно пытается защитить идеи (например, те, кто хочет, чтобы я подписал соглашение о неразглашении, когда делятся со мной простейшей идеей).

Я думаю, идеи ничего не стоят без реализации. Они – всего лишь множитель. Реализация стоит миллионов.

Объяснение:

Ужасная идея = -1
Слабая идея = 1
Идея ничего = 5
Хорошая идея = 10
Отличная идея = 15
Гениальная идея = 20

Без реализации = $1
Слабая реализация = $1000
Реализация так себе = $10 000
Хорошая реализация = $100 000
Отличная реализация = $1 000 000
Гениальная реализация = $10 000 000

Чтобы оценить компанию, нужно умножить одно на другое.

Гениальнейшая идея без реализации стоит $20.

Гениальнейшая идея с отличным исполнением стоит $20 000 000.

Поэтому я не хочу слышать идеи.

Мне неинтересно, пока не увижу реализацию.

Об авторе. Дерек Сиверс (Derek Sivers) — бизнесмен, основатель CD Baby.

Про лень...

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



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

Это топик Зла.
Это топик ненависти к СНГ-шной системе образования.
Этот топик написан потому что я хочу его написать самому себе на память.
Этот топик ненависти в программистам. Добро пожаловать под кат тем кто еще не поставил минус.

Сегодня у нас хорошие новости: как и обещали, мы открываем наш флагманский сайт Веб-стандарты. Это ресурс со статьями, новостями и анонсами событий Web Standards Days, созданный разработчиками для разработчиков.

В последнее время Вы, наверное, много слышали о том, что Flash является умирающей технологией и о том, как она будет вскоре заменена на HTML5. Лично я считаю, что HTML5 будет постепенно заменять Flash лишь для некоторых вещей, но Flash всегда будет иметь место, особенно при разработке сложных игр и насыщенных интернет-приложений. Если вы еще не видите, что можно сделать с помощью HTML5, я ограничусь десятью примерами, чтобы показать некоторые из возможностей HTML5.



Так что же вы думаете – HTML5 заменит Flash?

Наткнулся на Stackoverflow.com на интересный топик с вопросом о новом в программистском жаргоне. Предлагаю здесь подборку наиболее интересных выражений.

Египетские операторные скобки

if (a == b) {<br>  printf("hello");<br>}<br><br>

Проблема

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

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

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

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

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

Знаете, в чем на самом деле фишка? В разности целей!

Полная версия статьи из Financial Times тут для любителей аутентичного чтения :).
Financial Times опубликовала интервью с французским предпринимателем(теперь проживающим в Силиконовой Долине (Silicon Valley) Лоик ле Мер (Loic Le Meur).

Написание инструкций пользовательского интерфейса

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

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

Некоторым везет. Вы точно знаете такого. У него на столе широкоформатный монитор, которым можно заменить экран в кинотеатре. Компьютер, приютившийся под дорогим дубовым столом, мощнее WOPR из старого фильма «Военные игры». И, конечно же, не забываем, что всё это в отдельном кабинете, в котором даже можно закрыть дверь на ключ (само собой, по исключительно важным поводам). И если вам людишкам из-за офисных перегородок этого мало, то вспомните, что этот чувак отвечает за самые крутые проекты и использует самые сексуальные и новейшие технологий. Он из тех, кем все прочие смертные тоскливыми ночами мечтают быть, вместо того чтобы спать. Но какого же ему так везет?

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

"Отзывчивый" - в данной ситуации означает "изменяющийся в зависимости от окружающих реалий".

Предлагаю вниманию свой взгляд с иллюстрациями на сущность «отзывчивого», развиваемого дизайна. Меня заинтересовал конспект лекции об «отзывчивом дизайне», поскольку текущая наша разработка идёт именно в таком ключе — функционал добавляется понемногу, в процессе уточнения и переосмысления задач, без революций, с хорошим пренебрежением к академической идеальности и законченности, которой в процессе развития просто не имеет права быть. Это по-своему замечательно — пренебрегать правилами валидности (они — для будущего), кроссбраузерности (функционал есть, но отображается в IE c долей снисхождения) и концептуальности до момента, пока функционал системы не определён. Она имеет только те куски «мяса», которые работают, отработавшие куски постепенно удаляются. Именно это описывает Кент Бек в своей лекции, поэтому так живы и богаты ассоциации с его классификацией о четырёх стратегиях.

Добрый день, коллеги!

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

Ничто не предвещало (преамбула)

Приходит посредник (или представитель заказчика), приносит концепцию (почти всегда гордо именуемую ТЗ) и просит оценить фронт работ в человеко-часах или баксо-рублях. После просмотра предоставленного документа я прикидываю, что работа займет около x (икс) недель и будет стоить примерно y (игрек) денег. Оценочная прикидка, ничего более. При оценке учитывается, что ТЗ (концепция) штука достаточно расплывчатая, чтобы при его уточнении можно было бы упихать функциональности раз в 5 больше, чем нарисовано изначально и сам проект выше среднего по сложности, причем не социальщина какая-нибудь, а программно-аппаратный комплекс взаимодействующий ещё и со сторонними приложениями. Оценки высылаются запросившему. В ответ приходит письмо с просьбой расписать чуть подробнее. Опускаюсь на уровень ниже выделяю какие-то наиболее существенные подпроекты, высылаю. Получаю замечательный ответ: «Вы просите так много, что я даже не буду показывать это заказчику.» Где-то рядом крутится смайл с ВОТ ТАКИМИ глазами.