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

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

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

Про БЭМ (методология написания CSS от Яндекс — Блок__Элемент_Модификатор ← наиболее правильная запись расшифровки) нынче можно услышать на каждом шагу. Дело оказалось благим и покатилось по миру. Яндекс даже полез в W3C (связано это или нет — не знаю, но надеюсь, что да — [на самом деле нет]).

Думаю многие, кто ещё не пробовал, но прочитал описание БЭМ, задаются справедливым вопросом: «какая практическая польза от всего этого действа?» На самом деле, не смотря на то самое развёрнутое описание, конкретно уловить основную «фишку» довольно сложно. Описано конечно много плюсов и общее ощущение от методологии положительное, и кажется, что вроде как и не плохо бы попробовать, но нехватает чего-то конкретного. Прямо вот примера на живом что ли. Вот у меня сайт, вот вёрстка не по БЭМ, почему я должен всё менять? Особенно, если учесть тот факт, что БЭМ в принципе отметает все селекторы кроме классов, неужто за это время столько умных мужей в W3C не осознали, что всё настолько неправильно?

За сим возьму на себя смелость привести несколько примеров с которыми вы (конечно если вы каким-то образом связаны с вёрсткой) сталкиваетесь, не побоюсь этого слова, ежедневно. И что изменится в таких ситуациях если бы вёрстка была изначально выполнена в БЭМ.

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

Обзор кода является одним из наиболее эффективных методов поиска и устранения дефектов программы. Обзоры проводятся человеком, что позволяет находить широкий класс ошибок, в том числе с трудом детектируемых или вообще не детектируемых автоматическими средствами. Безусловно, обзор кода, не отменяет использование анализаторов кода или других методик обнаружения ошибок, например, unit-тестирования. К сожалению, не существует метода, который один обеспечил бы обнаружение всех дефектов программы (в исследованиях эффективность обзора кода обычно оценивается как 30-50% обнаруженных ошибок в приложении).

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

Часть 1: Поступление

Живет тут

Часть 2: Стоимость жизни в США

Живет тут

От издателей: Друзья, мы представляем вам русское издание великолепного исследования Developer Economics 2012. Весной мы, как региональные представители, собирали на Хабре разработчиков для представления России в этом исследовании и хотим поблагодарить всех принявших в нем участие — российские разработчики стали третьей силой в мире, после Китая и США. Мы подготовили русский перевод этого исследования и надеемся, что он будет полезен вам в вашей работе. Спасибо!

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

На Хабре присутствует довольно много бизнесменов, еще больше фрилансеров и работающих по найму.

Большинство из нас (уж я-то точно!) попалось в ловушку жизненной колеи, утверждённой социумом, как стандарт: школа => институт => работа по найму. Кто-то сразу подался во фриланс или бизнес.

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

Приступим к сравнению по набору параметров, которые я считаю наиболее важными, все оценки субъективны — на основании собственного опыта работы по найму + бизнеса, а также опыта работы знакомых по фрилансу.

Введение

МегаФон — динамичная технологическая компания, работа которой не ограничивается исключительно предоставлением услуг связи. Например, среди наших активов есть большое количество интернет-сайтов, на которых клиенты получают различную информацию и услуги. В рамках проекта по совершенствованию и развитию наших веб-проектов мы, в том числе, создаём продукты, которые могут быть полезны и другим разработчикам. Сегодня мы хотели бы представить первый из них — шаблонизатор Histone, который является opensource-проектом, распространяемым по лицензии Apache Software License 2.0. Но обо всём по порядку.

Что такое Histone?

Многие из вас при создании веб-приложений используют различные шаблонные движки. Ситуация, когда из данных, представленных в определенном формате, вам необходимо сгенерировать некий HTML-код при помощи шаблона, задающего правила преобразования, встречается повсеместно. Несколько лет назад шаблонизаторы активно использовались для генерации HTML-кода на сервере (Smarty, FreeMarker, Velocity), сегодня все чаще и чаще возникает необходимость производить генерацию HTML-кода непосредственно в браузере. В качестве примера таких шаблонизаторов можно привести: TrimPath templates, Mustache, Google Closure Templates и т. д.

В Интернет можно найти множество различающихся реализаций и схем, уже набившего оскомину, паттерна MVC. В разных книгах я также встречал разные схемы. Это порождает некоторую путаницу и комментарии к моей предыдущей статье: "Реализация MVC паттерна на примере создания сайта-визитки на PHP" тому подтверждение. В поисках истины, я попытался расставить все по местам… перечитал некоторую литературу и статьи по паттернам проектирования и написал дополнение к упомянутой статье. Но решил запостить это дополнение, как отдельный топик в надежде на фидбэк. Под катом вы найдете несколько часто встречающихся схем MVC и MVP с описанием жизненного цикла приложения, а также описание менее популярных паттернов HMVC и MVVM. Разумеется, некоторые из перечисленных паттернов применимы не только к веб-приложениям, но в статье они рассматриваются именно в этом контексте.

В 2010 году Apache Hadoop, MapReduce и ассоциированные с ними технологии привели к распространению нового явления в сфере информационных технологий, названного «большими данными» или «Big Data». Понимание того, что из себя представляет платформа Apache Hadoop, зачем она нужна и для чего её можно использовать потихоньку проникает в умы специалистов по всему миру. Зарожденный, как идея одного человека, и быстро выросший до промышленных масштабов, Apache Hadoop стал одной из самых широко обсуждаемых платформ для распределенных вычислений, а также платформой для хранения неструктурированной или слабо структурированной информации. В этой статье я хотел бы подробнее остановиться на самой платформе Apache Hadoop и рассмотреть коммерческие реализации, предоставляемые сторонними компаниями, и их отличия от свободно распространяемой версии Apache Hadoop.

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


У нас в программе: вольный пересказ спек OAuth2, слабые стороны и Threat Model, 0day на хабретрюк с аутенфикацией.

Постепенно в грязных подвалах мозга начинается структурироваться информация по госзакупкам и знаменитому 94 ФЗ. Довелось поработать со стороны заказчика и со стороны исполнителя, а также изучить опыт организации взаимодействия государства и бизнеса в США.


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

Нервных попрошу не смотреть.

Данная заметка является дополнением к прочим, уже опубликованным на хабре, статьям, посвященным работе с иностранными заказчиками из России. В последней подобной статье, написанной пользователем mag есть замечательный ссылки и комментарии. Поэтому если вы еще не ознакомились с означенной статьёй, то рекомендую ознакомится. Хотя, моя, заметка озаглавлена как oDesk специфичная, она, также, будет содержать некоторые ссылки и советы, которые могут быть применены и при работе с другими типами-источниками влекущими за собой ВЭД(Внешне Экономическая Деятельность). Но, всё же, если вы собираетесь работать с заказчиками напрямую, т.е. все ваши расчеты будут напрямую, то всё это хорошо описано в предыдущих статьях.

Прошло много времени, прежде чем я созрел на написание второй части статьи, посвященной управлению конфигурациями. Тому, что это наконец таки свершилось способствует тот факт, что не так давно мне посчастливилось выступать на конференции PHPCONF 2009 8 октября (Web Architect Workshop Day) с мастер-классом «Метод организации репозитория исходного кода». Для выступления были заблаговременно подготовлены презентация, а также текст доклада. Несмотря на отличную организацию мероприятия, для публичного доступа так и не были выложены материалы докладов, входящих в программу конференции. В качестве компенсации я решил таки опубликовать материал, использованный в моем выступлении. Кроме данной статьи, (которая является логическим продолжением предыдущей), посвященной конфигурационному менеджменту, для публичного обозрения доступны слайды презентации.
В данной статье пойдет речь об инструментах, использующихся при управлении конфигурациями. Поэтому в первую очередь хотелось бы заострить внимание на том, как инструменты, использующиеся в разработке могут влиять на процесс создания ПО.

Существует достаточно много цифровых сертификатов, каждый из которых служит для своих целей. Самые распространенный тип сертификатов это естественно SSL сертификаты, которые также имеют несколько подвидов. Также существуют Code Signing сертификаты, Website Anti Malware Scanner сертификаты и Unified Communications сертификаты.

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

Так что если у вас стоит задача поднять защищенное https соединение для вашего сайта, то в этом посте я постараюсь раскрыть все тонкости и особенности SSL сертификатов, чтобы сделать правильный выбор было проще.

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

Если говорить о языке C#, то его разработчики подходят к вопросам «юзабилити» весьма основательно; они спокойно могут пожертвовать «объектной чистотой» в угоду здравому смыслу и удобству использования. Одним из немногих исключений из этого правила является замыкание на переменной цикла, той самой фичи, которая ведет себя не так, как считают многие разработчики. При этом количество недовольства и недопонимания настолько много, что в 5-й версии языка C# это поведение решили изменить.

abstract: В статье описаны продвинутые функций OpenSSH, которые позволяют сильно упростить жизнь системным администраторам и программистам, которые не боятся шелла. В отличие от большинства руководств, которые кроме ключей и -L/D/R опций ничего не описывают, я попытался собрать все интересные фичи и удобства, которые с собой несёт ssh.

Предупреждение: пост очень объёмный, но для удобства использования я решил не резать его на части.

Оглавление:

• управление ключами
• копирование файлов через ssh
• Проброс потоков ввода/вывода
• Монтирование удалённой FS через ssh
• Удалённое исполнение кода
• Алиасы и опции для подключений в .ssh/config
• Опции по-умолчанию
• Проброс X-сервера
• ssh в качестве socks-proxy
• Проброс портов — прямой и обратный
• Реверс-сокс-прокси
• туннелирование L2/L3 трафика
• Проброс агента авторизации
• Туннелирование ssh через ssh сквозь недоверенный сервер (с большой вероятностью вы этого не знаете)

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

Требования к инструменту

На мой взгляд, такой инструмент должен:

1. Быть интегрирован с системой баг-трекинга, чтобы можно было заводить дефекты по мере их обнаружения
2. Автоматически документировать обнаруженный дефект. Это важно, когда тест идёт не по сценарию, а в произвольной последовательности, которую невозможно держать в голове
3. Обеспечивать возможность повторения последовательности исследовательского теста
4. Быть интегрирован с системой управления требованиями — чтобы по возможности привязывать обнаруженные дефекты к требованиям
5. Быть интегрирован с системой управления тестами, чтобы:

• проводить все виды тестирования в единой среде
• создавать новые сценарии тестирования на основе исследовательских тестов

Собственно, оптимальным вариантом в этом смысле будет наличие поддержки исследовательского тестирования в интегрированном инструменте управления требованиями, тестами и дефектами. Об одном из таких инструментов — Microsoft Test Manager 2012 — я и хочу рассказать.
В 2012-й версии MTM появилась поддержка исследовательского тестирования. Способы применения этого функционала мне видятся следующие:

1. Проведение исследовательского тестирования в дополнение к тестам по сценариям
2. Проведение тестирования в условиях отсутствия сценариев тестирования
3. Быстрое создание новых сценариев тестирования через сеансы исследовательского тестирования

Доброго времени суток, коллеги.

Сразу хочу оговориться, что данная заметка… это просто заметка по некоей технической проблеме, которая, как кажется автору, имеет некоторое отношение к тематике раздела, где она публикуется.
Вот здесь habrahabr.ru/post/148200 уже затрагивалась тема проксирования через бесплатные VPN сервисы, теперь речь пойдет о мобильном интернете.

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



Понять последних можно, ведь большинство статей и agile-евангелистов говорят, примерно следующее: «Делайте так, как говорит методология, и ваш проект попадёт в рай. Если нарушите хотя бы одну из практик, то Agile покарает вас»

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