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

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

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

Мы продолжаем публиковать статьи о разработке и производстве сложной современной электроники. В этот раз расскажем об изготовлении прототипов и опытных образцов. Любой проект включает в себя эту стадию, от ее результатов зависит дальнейшая судьба устройства — выход на массовое производство или отправка на доработку.
 
Рабочий образец воплощает в себе результаты работы инженеров, программистов, промдизайнеров и технологов. Его щупают, рассматривают и оценивают, сравнивая ожидаемое с действительным.
 
Зачем вообще нужны эти прототипы? Сколько штук их нужно изготовить в рамках проекта и сколько это стоит? Какие документы нужны для производства опытных образцов? Ответы на эти вопросы вы найдете под катом.
 

Не все задачи успели мы с вами обозреть в предыдущем посте, поэтому продолжать будем в этом.

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

То есть как — психология?

Некоторые наши специализированные компании, предоставляющие услуги на рынке юзабилити, уже много лет укомплектованы дипломированными психологами (чаще всего, выпускниками кафедр инженерной или общей психологии). Действительно, уже более полувека русскоязычная психология исследует процесс взаимодействия человека и техники (первая наша книга по теме) и, в частности, интерфейсы между оператором и техническим устройством. Конечно, терминология эта носит сугубо эргономический характер, однако это не затрудняет перенос знаний в IT-среду (например, Дмитрий Сатин, основатель UsabilityLab, является выпускником самой эргономической кафедры факультета психологии МГУ).
Психологическое знание в России популяризируется слабо, хотя само по себе может быть очень полезным для разработки программных продуктов. Я попытаюсь коротко изложить некоторые базовые принципы проектирования — как их видно изнутри классических психологических (преимущественно, когнитивных) работ. Я уверен, что буфер, которым является юзабилити, IT-индустрии не нужен: психологические знания можно научиться применять напрямую.

Пользуясь тем, что на Хабре проходит очередной месячник квайнов (см., например, Теорема Клини о неподвижной точке: квайны или Мультиязыковые квайны), рискну рассказать и одну свою историю. В ней не будет таких сложностей и заумствований, как в упомянутых топиках, поэтому данный текст можно воспринимать как пятничное развлечение.

Дело происходило почти четверть века назад, в эпоху отсутствия всеобщей компьютеризации и интернета. Возник у меня как-то вопрос — а можно ли написать программу, выводящую свой собственный текст. Слова «квайн» в те времена никто из моих знакомых не знал, а посмотреть в википедии я не мог «за отсутствием таковой» (с).
Промучался я над этой задачкой неделю, но таки победил её. Программа получилась корявенькая, длинная, но требованию удовлетворяла. Ужасно гордый собой, я начал предлагать эту задачу всем своим друзьям. По ходу дела пришлось уточнять условия — нельзя читать из файла, программа должна быть не пустой. Обычно после этого товарищи надолго задумывались.
Однако, один из друзей мне моментально ответил, что это, дескать, элементарно, и тут же предоставил мне требуемую программу, удовлетворяющую поставленным условиям.
Оказалось, что я всё-таки упустил одно важное и, казалось-бы, очевидное условие. Однако без его явного упоминания задачка действительно становится тривиальной. Тем не менее даже в современной статье о квайнах в википедии это условие почему-то отсутствует. Хотите знать, что это за условие?

Многие Руби-разработчики игнорируют потоки (threads), хотя это очень полезный инструмент. В данной статье мы рассмотрим создание IO потоков в Руби и покажем как Руби справляется с потоками в которых происходит много вычислительных операций. Попробуем применить альтернативные имплементации Руби, а так же узнаем, каких результатов можно добиться при помощи модуля DRb. В конце статьи посмотрим, как эти принципы используются в различных серверах для приложений на Ruby on Rails.

IO потоки в Руби

Рассмотрим небольшой пример:

def call_remote(host)
  sleep 3 # симулируем долгий запрос к серверу
end

Если нам надо обратитьcя к двум серверам, например, чтобы очистить кэш, и мы дважды последовательно вызовем эту функцию:

call_remote 'host1/clear_caches'
call_remote 'host2/clear_caches'

то наша программа будет работать 6 секунд.

Мы можем ускорить исполнение программы, если будем использовать потоки, например, так:

threads = []

['host1', 'host2'].each do |host|
  threads << Thread.new do
    call_remote "#{host}/clear_caches"
  end
end

threads.each(&:join)

Мы создали два потока, в каждом потоке обратились к своему серверу и командами #join сказали, что главной программе (главному потоку) надо подождать их завершения. Теперь наша программа успешно выполняется в два раза быстрее, за 3 секунды.

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

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

Недавно мне довелось на собственном опыте убедиться: чтобы научиться применять какие-то новые технологии, недостаточно прочитать пару книг по теме, потому что без практики теория мгновенно улетучивается из головы.

Но что можно сделать такого интересного на Scala? На самом деле, выбор не слишком большой. Я как-то придумал небольшую тулзу, неспешно написал ее, и «забил». А через несколько месяцев, к своему стыду, гуглил синтаксис «for loop»…

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

Я переписал на Scala и выложил на GitHub парочку примеров. На скрине как раз один из них — MSA Fluids. Заинтересовавшихся прошу под кат.

Я прочитал очень-очень интересную статью «Стратегии управления памятью для Erlang VM». Она была написана в качестве диссертации Джеспером Вильхельмсоном. Я подумал, что было бы неплохо обсудить различия между управлением памятью в Erlang и Java VM от Oracle.

Не так давно, в команду пришлось приглашать нового программиста и знакомить его с Erlang. Для ускорения процесса обучения я решил перевести уже давно лежавший у меня материал Erlang Programming Rules and Conventions. Чем в принципе и хочу поделиться с хабровчанами. Надеюсь что он будет полезен тем, кто собирается изучать или уже использует этот замечательный язык. Сразу скажу, что перевод вольный, так что не критикуйте сильно.

Представляем вашему вниманию доклад Максима Лапшина, сделанный им на конференции Application Developer Days. Мы собрали воедино видео и аудио, слайды презентации, а также стенограмму доклада. Последнее потребовало огромных усилий, но оно явно того стоит. Сорокаминутный доклад можно «услышать» в несколько раз быстрее.

Свел видео и презентацию в единый ролик, а также записал стенограмму Стас Фомин (человек и пароход локомотив :)).

— … Тут я даю ему по морд… Нет, бить нельзя!
— В том-то и дело, что бить нельзя, — лицемерно вздохнул Паниковский. — Бендер не позволяет.
И.Ильф, Е.Петров. Золотой теленок.

Мозголомная Брага жила в прозрачном сосуде и была такая
крепкая, что даже ужас. Она не то что из живота — прямо изо рта
бросилась в голову и стала кидаться там из стороны в сторону,
ломая умственные подпорки и укрепы.
М.Успенский. Там, где нас нет.

Пожалуй каждый, кто впервые приступает к изучению Erlang, ощущает себя в положении Шуры Балаганова, которому запрещено было применение единственного доступного и понятного метода: «бить нельзя...». В Erlang отсутствуют такие привычные для большинства современных языков понятия, как повторное присвоение переменной и, соответственно, накопление результата в одной переменной. (Справедливости ради следует отметить, что поведение типа «глобальная многократно меняющаяся переменная» в Erlang все же можно реализовать. Для этого в каждом процессе имеется словарь хешей, хранящий определяемые программистом пары ключ — значение. Имеются встроенные функции put(Key, Value), get(Key) и еще несколько вспомогательных функций. Но использование такого словаря в приложениях считается плохим стилем и рекомендуется только в исключительных случаях (http://www.erlang.org/doc/man/erlang.html\#put-2)). Как следствие, итерации в цикле невозможно реализовать с помощью привычного наращивания значений итерационной переменной. Накопление результата осуществляется только через рекурсию, а организация циклов — через хвостовую рекурсию. (Конечно, и итерации, и накопление результата в цикле можно реализовать через библиотечные функции для списков lists:foreach(Function, List), lists:foldl(Function, StartValue, List), lists:foldr(Function, StartValue, List) (http://www.erlang.org/doc/man/lists.html) и их аналоги для наборов (http://www.erlang.org/doc/man/sets.html, http://www.erlang.org/doc/man/ordsets.html, http://www.erlang.org/doc/man/gb_sets.html) и массивов (http://www.erlang.org/doc/man/array.html). Но наша цель — научиться писать циклы, а не использовать готовые решения, поэтому здесь мы воздержимся от употребления подобных библиотек).

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

В житии святого Антония Великого есть рассказ об одном из его учеников. Ученик стоял в храме и слушал, как святой Антоний читал Псалтырь. Как только прозвучал первый стих первого псалма:
Блажен муж, который не ходит на совет нечестивых...
ученик вышел из храма. С тех пор его никто не видел почти 30 лет, а когда он вновь появился в храме, Антоний Великий спросил, почему он оставил их так надолго и куда исчез. Ученик ответил: «отче, я услышал слова псалма, и удалился в пустыню, чтобы постараться выполнить то, о чем говорится в этих словах, т.е. не ходить на совет нечестивых мыслей». Другими словами, он усвоил практический урок этих слов, и теперь пришел чтобы читать дальше. К сожалению, у нас нет такого резерва времени, да и цели наши не столь возвышенны. Но основной концепт можно перенять.
Мы рассмотрим две стандартные комбинаторные задачи:

1. поиск всех возможных перестановок (permutations) из данного множества по N элементов
2. поиск всех возможных сочетаний (combinations) из данного множества по N элементов

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

0 Преамбула

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

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

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

А что такого можно написать на Scala, чего нельзя на Java?
(из разговора с одним моим знакомым другом, человеком и программистом)

The best reason to learn a new programming language is to learn to think differently.
Chad Fowler

Хочу рассказать не о простоте конструкций Scala по сравнению с Java и не о том, что в 1 строчку Scala я могу уместить 20 строк Java. А наоборот, копнуть поглубже, уронить устои ООП и посмотреть на реакцию благородной публики.

«Chicago Boss — бескомпромиссный веб-фреймворк, любимый дизайнерами, инженерами и этим парнем с пейджером.» — © chicagoboss.org

«Erlang — язык для создания отказоустойчивых распределенных приложений. Это — один из немногих функциональных языков, который давно и успешно применяется на практике. Например — в телекомах (Ericsson AXD-301 switch), банковских системах, системах автоматизации, высоконагруженных веб-приложениях (Facebook Chat). При этом Erlang — продукт с открытым исходным кодом и распространяется бесплатно.» — говорит нам сайт русскоязычного сообщества Erlang.

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

По заверению обоих разработка веб-приложений на базе этого фреймворка ничуть не медленнее разработки на тех же рельсах (Ruby on Rails). А в чем-то даже быстрее. Я с функциональным программированием до этого особо знаком не был, но под давлением товарища решил попробовать. Хочу сказать, что опыт был весьма удачным и у меня получилось создать мой первый веб-сайт быстрее, чем год назад с тем же Ruby on Rails.

У меня есть сайт, написанный на Node.js, и иногда там требуется сделать что-то, для чего Node.js не предназначен: например, произвести какие-нибудь математические вычисления.

В этом примере мы будем вычислять «хеш» пароля.

Java существует достаточно долго, на ней написано огромное количество софта и она является лидером в своей области. Однако Java не лишена недостатков. При проектировании языка важным критерием была простота и легкость изучения языка, и эта простота заставляет писать огромное количество лишнего кода, что бы компенсировать недостаточную гибкость языка: паттерны проектирования, XML конфиги, AOP, гетеры-сеттеры, try catch finaly синтаксис и т.д. Так же очевидно что не для всех задач чистый ООП подход является оптимальным, некоторые задачи намного эффективнее выполнять в функциональном стиле.

Существует много разных языков — Groovy, Python, Ruby, JRuby и еще много других, которые потенциально могут заменить java. Так почему же именно Scala?

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

Думаю, IT-примеры вам и так прекрасно знакомы, поэтому напомню пример из книги «Психология влияния»: психологи обзванивали медсестёр в больницах, а затем представлялись врачом и отдавали распоряжение ввести смертельную дозу вещества пациенту. Сестра знала, что делает, но в 95% случаев выполняла команду (её останавливали на входе в палату ассистенты психолога). При этом врач даже не был хоть как-то авторизован. Почему сестра так делала? Просто потому, что она привыкла слушаться авторитета.

Давайте ещё раз: в примере благодаря грамотной социальной инженерии 95% больниц оказались критически уязвимы.

Что такое стриминг?

Стриминг крутился около Rails начиная с версии 3.2, но он был ограничен исключительно стримингом шаблонов. Rails 4 же вышел с более зрелым функционалом стриминга в реальном времени. По сути это значит что Rails сейчас способен нативно обрабатывать I/O объекты и посылать данные клиенту в риалтайме.

Streaming и Live — два отдельных модуля, реализованных внутри ActionController'а. Streaming включен по умолчанию, в то время как Live должен быть явно добавлен непосредственно в контроллере.

Основной api стриминга использует класс Fiber (доступен с версии ruby 1.9.2). Файберы предоставляют инструментарий для потоко-подобного параллелизма в ruby. Fiber дает возможность потокам приостанавливаться и возобновлять работу по желанию программиста, а не быть по сути упреждающими.