Cтэнфордский курс CS183B: How to start a startup. Стартовал в 2012 году под руководством Питера Тиля. Осенью 2014 года прошла новая серия лекций ведущих предпринимателей и экспертов Y Combinator:

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

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

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

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

Основный недостаток большинства оценочных процедур – их субъективность, низкая надежность при оценке знаний и навыков человека. Люди не хотят говорить правду, зачастую выдают теоретические знания за практические навыки. Чтобы отобрать правильных кандидатов, разработаны несколько видов интервью. Одно из них – это поведенческое – то из немногих, которое действительно позволяет понять, что же реально знает и умеет кандидат.

Читать дальше – будет много букв и примеров …

Как в фильме Начало (Inсeption), реальность в продуктовой разработке имеет определенную вложенность слоев. В зависимости от того, какая роль вам выпала, ваше “начало” в проекте может произойти раньше или позже, но всегда приятнее быть в числе создателей новой реальности, не так ли?

Эта статья — вступительная часть к трилогии о том, что собой представляет в гибкой продуктовой разработке:

• Готовность Начать
• Готовность Завершить
• Готовность Выпустить

Первая часть будет посвящена процессу открытия продукта (Product Discovery), вторая — процессу разработки продукта (Agile Delivery), третья — формированию цикла этих двух процессов, с обратной связью от рынка (Business Development). Здесь же, в начале, я задам общие рамки ролей и процессов, в которые буду углубляться в следующих частях.

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

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

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

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

Мир тебе, %username%!

В этой серии постов я хочу рассказать о некоторых аспектах реализации платежной системы(а если повезет и двух), реально имевшей честь работать с середины 2000х в одном из городов нашей необъятной родины.
Что вообще такое ПС, и по каким принципам она должна работать? Я, как и заказчик, имел об этом представление лишь как пользователь WebMoney и платежных терминалов. Тем не менее, желание+деньги сделали своё дело и разработка началась.

Для начала, что вообще понималось под платежной системой и с чего началась разработка.
UPD:
Вторая часть!

Итак, вы новичок в WPF или Silverlight и желаете знать с чего вам начать? Здесь описан мой путь изучения “Как начать с WPF и Silverlight”. Я предполагаю, что вы знаете что из себя представляют эти технологии (на высоком уровне), но не знаете как использовать их.

Доступен для бесплатного скачивания финальный вариант книги Application Architecture Guide во второй редакции. Книга содержит 560 страниц разбитых на 28 больших глав. Application Architecture Guide посвящена архитектуре и дизайну ПО, как то: дизайну и разработке различных типов ПО (мобильные, web, клиентские, RIA, сервисы и облачные сервисы), организации и разработке уровней ПО (представления, бизнеслогики, данных, сервисов), созданию компонентов.

Получить книгу можно несколькими путями:
* скачать pdf (7.5 Mb);
* читать online;
* купить на Amazon;
* скачать дополнительную информацию на App Arch Guide 2.0 Knowledge Base.

Официальный анонс одного из авторов в его блоге J.D. Meier's Blog.

Введение

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

В IT индустрии все чаще встречаются проекты с распределенными командами. Это удобно — спецификация, код, баги, мануалы легко перемещаются из одного конца планеты в другой за доли секунд. Это выгодно — аутсорсинг проектных процессов, будь то разработка, тестирование или саппорт, в Индии или Китае обойдется в 3–5 раз дешевле аналогичных сервисов в странах Европы или США.

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

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

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

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

ВНИМАНИЕ: в статье имеется большое количество крупных изображений.

Коллеги, хотелось бы услышать Ваши мысли по поводу идеи виртуальной бизнес-сети.

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

Развитие и популярность социальных сетей заставило разработчиков и бизнесменов задуматься над использованием принципов работы социальных сетей в бизнесе. Там и тут слышится «business goes social», «entreprise 2.0» и тому подобное. Мы рассмотрели новшества, предлагаемые разработчиками подобных сервисов и пришли к выводу, что все нововведения ограничиваются добавлением коммуникативных инструментов социальных сетей в бизнес-приложения. Однако мы не встретили сервиса или даже призыва к созданию бизнес-сетей наподобие того, как создаются социальные сети: моя компания – мои партнеры – партнеры моих партнеров, мои клиенты — все в одном месте, все формализовано и систематизировано.

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

Люди уже давно научились планировать и описывать процессы при помощи практик календарно-сетевого планирования, ярким представителем которых является диаграмма Гантта. Разработано и обкатано множество программных инструментов, легко доступных любому желающему.

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

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

По работе с Жирой:

1. Вводятся следующие понятия:
sub-task - подзадача,
versions - версии продукта, привязанные к определенной дате, это наше внутреннее обозначение, номер версии = год+неделя, т.е. 0852 - версия 2008 года, 52-я неделя
components - компоненты системы, это как колеса, двигатель, кузов у автомобиля
estimated time - исходная оценка, т.е. предварительная оценка времени на выполнение задачи

2. До начала работы над задачей - провести предварительную оценку требуемого времени и зафиксировать эту оценку в поле "Estimated time - Исходная оценка" - (в режиме редактирования) - это обязательное требование. Кто: Project Leader или Developer.

3. Непосредственно перед началом работы над задачей необходимо установить дату предполагаемого окончания работы "Срок исполнения" (в режиме редактирования), с учетом текущей даты и "Исходной оценки" - это обязательное требование. Кто: Developer

4. Components - фиксируется список компонентов системы, список дополняется/изменяется по необходимости. Кто: Project Leader

5. Versions -
Следующие задачи: выполненные, в работе, имеющие предварительную оценку открытые - интегрируются в Версии Продукта. Примерный график выпуска версий - один раз в две недели. Кто: Management+Project Leader - это обязательное требование.

Хорошего дня,