?

Log in

No account? Create an account

Entries by category: it

Ответ на бнопню по C++

Код, который напрямую зовёт std::vector{std::move(foo)} на данных в ощущениях компиляторах (gcc, clang) будет медленнее, чем construct_vector(std::move(foo)), где:

std::vector construct_vector(Foo && foo) {
    std::vector vec;
    vec.emplace_back(std::move(foo));
    return vec;
}


Почему это так случается? Из-за отсутствия оптимизации std::initializer_list. Конструкция вектора через std::vector{} создаёт initializer_list, мувает в него один элемент foo, затем копирует из initializer_list внутрь вектора. К сожалению.

construct_vector же копированием foo не занимается, а делает move construction. Значение вектора попадает в место вызова без копирования, через RVO.

Ну вот так хреново пока работаем с std::initializer_list. В стандарте C14 про это вот что есть: "the underlying array is copy-initialized". Опаньки.

Типичный C++, что ни фича, то засада. JavaScript и то без копирования передавал бы всё :)

P.S. По поводу «почему C++» (mpd) — это было не моё решение. Нам и на Эрланге с сишными вставками неплохо работалось, правда, в сервис работал в десять раз медленнее. Но если у компании есть ресурсы и время на то, чтобы создать поддерживать в тонусе команду C++-програмистов, почему бы и нет? :)

Ключевой момент тут такой: если не заниматься байтодрочерством, C++ из-за подобных недофич (чуть что — копируем! ну или не смогли понять жизненный цикл — тоже на всякий случай скопируем) будет работать не сильно быстрее остальных дефолтных языков, а то и медленнее и/или глючнее. Только если действительно понимать, что происходит, можно выжрать нетривиальный буст по производительности, и, если повезёт, не сильно потерять в безопасности. Но это если такая производительность действительно нужна. На мобилке она, за редкими исключениями, вряд ли нужна. В датацентре (если это не cuda) — уже более интересное распределение. Разница между десятью нодами и сотней нод в плане управления — колоссальна. Между сотней и тысячью — уже речь встаёт о дешевизне датацентра по сравнению с рабочим временем программиста.

Если C++ на вашем продукте позволяет обеспечить эту разницу в 10x, есть средства на программистов и время на их реализацию, почему бы и нет? У нас в MZ — есть. Компания зарабатывает несколько миллионов долларов в день. А в вашем НИИГиТ наверняка нет ни таких средств, ни таких требований к производительности, которые бы требовали кластера из более чем десятка машин, а их оптимизация явно встанет зарплатой программистов дороже, чем выгода от их сокращения.

Pandoc and Manual Pages

Итак, надоело мне рисовать мануальные страницы через nroff. Как в asn1c, например:



Проблемы с подготовкой документации в nroff такие:
Проблемы с nroffCollapse )
Что-то я не понимаю эти вот страдания по поводу того, что покрытие кода не 100%. Ну допустим ваша тулза показывает 100%. Что это значит, можно конюшни больше не чистить? А вот и нет:

int f(int a, int b) {
  int arr[2] = { 0, 0 };
  int i = 1;

  if(a == 1) i--;

  if(b == 1) i--;

  return arr[i];
}

И что это вам дало? Покрытие по строчкам 100%, а всё падает.

По опыту, у 84% программистов какой-то blind spot, не позволяющий ощутить масштаб проблемы.

Чувствую себя капитаном, пиша этот пост. Но он нужен.

Keyless SSL™ (shameless plug)

CloudFlare анонсировал, что теперь можно не раздавать сертификаты точкам, которые терминируют SSL трафик.

[1] http://blog.cloudflare.com/announcing-keyless-ssl-all-the-benefits-of-cloudflare-without-having-to-turn-over-your-private-ssl-keys/
[2] https://blog.cloudflare.com/keyless-ssl-the-nitty-gritty-technical-details/

И это на самом деле здорово. Только они так говорят, как будто это инжениринговый прорыв нереальный.

В начале двухтысячных у нас в Netli (продались Akamai) появилось желание терминировать SSL, причём, чтобы наши датацентры, стоящие в Китае, Бразилии, России и ещё чёрт-те где, не имели бы приватного SSL-сертификата. Потому что несекьюрно и может утечь. Среди наших клиентов были такие компании, как Dell (dell.com), HP (hp.com), и сертификаты этих сайтов было бы очень грустно утратить в процессе обработки их на этих разнесённых датацентрах.

В районе 2003-2004 я имплементировал этот процесс в виде расширения OpenSSL (добавил туда fibers, чтобы можно было асинхронизировать запросы; изначально в OpenSSL этот процесс синхронен), и набора софта "keyserver", при котором бы ключи хранились на центральных машинах в штатах, а на краевых машинах, в левых датацентрах, терминация SSL приводила бы к асинхронному запросу на генерацию pre-master ключа. На централизованных keyservers ключи на диске хранились в зашифрованном блобе, а ключ от блоба хранился в HSM (от nCipher) в центральном сервере, и передавался кейсерверам только временно.

Процесс мы не запатентовали, потому что наши предыдущие патенты, связанные с простыми инженерными шнягами, шли туговато. Например, моя глупая аппликация US20060098645 так и не прошла.

С тех пор эта же технология безключевого SSL светилась несколько раз в разных патентных аппликациях:

http://www.google.com/patents/US20070074282 (Certeon)
http://www.google.com/patents/US20130156189 (Akamai) — это выглядит ровно как описание моей работы — ну да не мудрено, потому что Akamai купил Netli целиком вместе с её кодом и клиентами, использовавшими безключевую терминацию SSL.

Но эти апликации не прошли. А вот более поздняя апликация от CloudFlare — прошла, и превратилась в патент:

https://www.google.com/patents/US8782774 (CloudFlare)

Вывод? Молодцы, я рад за них ;) Только патент у них non-enforceable, потому что есть prior art, закреплённый в патентах от Certeon и Akamai.

Tags:

Serendipities in Silicon Valley

Когда я переехал в Долину, столкнулся здесь с одной из необычных забав в разговорах. Люди вспоминают, кого куда "звали", а они решили туда не пойти, потом жалели. Один из первых запомнившихся мне разговоров был чем-то вроде «Тут ко мне подходит чувак, говорит что он Джерри, и у них наклёвывается такая клёвая новая конторка и нужен сисадмин. Я ему говорю, нет, мол, работа есть уже. Этой конторкой оказалось Yahoo и я был бы сотрудником номер 5, и мог бы купить остров.»

Я теперь тоже могу участвовать в таких разговорах ;)

лева привет

меня зовут ян.

you probably don't now me. i am CEO and co-founder of WhatsApp. i see you done some erlang/server stuff work in the past which is pretty amazing.

[...]

-- jan


2011 год. Блин.

P. S. 19 миллиардов долларов. Я рад за них! :)

Tags:

Сегодня мы пытаемся кратко просуммировать, что творится с веб-разработкой в масштабах всего веба, и делаем прогнозы на то, как будет выглядеть веб-разработка через 2-3 года.

Яков-зачинатель: http://jakobz.livejournal.com/236681.html
Ваня-продолжатель: http://gliv.livejournal.com/125078.html
Никита-тролль: http://tonsky.livejournal.com/285722.html

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

1. Очень разнятся скиллы тех, кто приходит в отрасль. От учителей истории, которые переучились на курсах (если повезёт), до дизайнеров и программистов на коболе. У них всех очень разные представления о том, что такое программирование. Очень разная толерантность к крутизне кривых обучения. Очень разные задачи. Поэтому будет продолжаться наблюдаться множество локальных оптимумов языков, фреймворков, и их комбинаций.
2. Веб-программирование как ниша развивается очень быстро. Ещё недавно SPA не было и JS использовался в качестве свистелок и перделок для статического сайта. Теперь на нём и SPA, и мобайл, и энтерпрайз. Пока эта область развивается (а она всё ещё развивается, краёв почти не видно), будет постоянный импеданс между возможностями, предоставляемыми подходами к программированию (нарисуйте и продолжите вектор от jquery как энхансер до Flight как фреймворк, и далее), и требованиями очередного витка развития.
3. Интерплей между языками программирования и фреймворками очевидно, порождает "косые" решения и неоптимальности, когда замечательный язык не имеет хорошего сопряжения с замечательным фреймворком (Roy/Elm + React?), и наоборот. Придётся страдать.
4. Некоторые подходы в программировании, такие как в FP, требуют отдельной фазы погружения программиста в них. Желательно, через что-нибудь чистое, типа хаскеля. Немногие хьюманы смогут пройти этот энергетически-временной барьер, поэтому объективно более лёгкие в использовании и развитии (при наличии в голове уже готовой и прогретой FP-парадигмы и, скажем, STM) фреймворки не смогут набрать себе критическую массу пользователей, а значит, будут всё время отставать с точки зрения развитости фреймворков и способности на них быстро набросать какой-нибудь state of the art интерфейс.
5. Разговор о языках и фреймворках остаётся не более чем вкусовщиной вплоть до тех пор, пока не начинает влиять на бизнес. Разговор об интересных языках и фреймворках сам по себе может усиливать вероятность успеха компании, потому что компания будет иметь возможность легче привлекать интересных людей. Или снижать вероятность успеха, потому что вместо практичных людей будет набирать черт-знает кого, кто понапихает в проект каких-нибудь скобок, потом хрен с ними разберёшься, хоть индусам раздавай переписывать всё нафиг. В любом случае не исключена парадоксальная ситуация, когда 1) компания наняла умных людей; 2) у компании таки будет успех; 3) но при этом те инструменты, которые они используют, являются энергетически даже менее оптимальными, более проблемными, чем обычнейшая связка из традиционнейших инструментов типа JS+Bootstrap.

Короче, тут пространство решений огромное, и множество локальных энергетических минимумов. Рассуждать о том, что "выиграет" особого смысла для принятия решений о выборе языка в конкретной компании не имеет, потому что в течение ближайших 10 лет "выигрышное" в индустрии решение почти всегда будет отличаться от выигрышного решения в рамках конкретного коллектива.

Clojure at Echo

Originally posted by tonsky at Clojure at Echo
Провел в команде опрос на тему Кложи. Опрошено три респондента с 4-5 месячным опытом использования (основные разработчики нашего clojure-driven продукта) и двое с 1-2 месячным (переключились на другой проект). Результаты анонимизированы и подсокращены до смысловой части.

Насколько сложно читать?

— Несложно, дело привычки
— Читать сложнее Эрленга
— Python (2,3) < Java, Erlang (4) < Clojure(6,7)
— Примерно Ruby (без Rails)
— Очень зависит от автора

Насколько сложно писать?

— Очень легко
— Легче, чем в ООП языках
— Меньше кода, только суть
— Упирается в понимание кода
— Проблем с отладкой не возникает (отладочная печать она и в Африке отладочная печать)

Как быстро начинает получаться писать что-то полезное?

— Неделя
— Недели две
— От недели и больше
— С учетом, что есть опыт в ФП

Наиболее сложные области

— Concurrency примитивы
— Двухсторонний interop
— Meta параметры
— Идеология

Стала ли Clojure естественным, «своим» языком?

Все: Пока нет, но потенциально да.

Полезно

— Гибкость, лаконичность
— Особенно чувствуется при переключении на другой язык
— Скорость написания кода («опа-опа и готово»)
— Java—библиотеки
— Синтаксис удобен для файлов конфигурации

Раздражает

— Скобки (1 чел.)
— Привязанность к Java (2 чел.)
— Непрозрачность кода из-за макросов (2 чел.)
— Медленный старт, тяжеловесность платформы (2 чел.)

Общее впечатление

— Писать на Clojure очень легко. Видимо поэтому мы так много пишем и переписываем то, что пишем.

— Большая неограниченная свобода. Можно писать как угодно и в любом стиле. Код становится зеркалом разработчика.

— Clojure идеально подходит для соло проектов и достаточно плохо подходит для командной разработки.

Наиболее полезные ресурсы

clojure.org
clojuredocs.org
— The Joy of Clojure
— Clojure Programming
— Programming Clojure


От себя (lionet). Вот этот пункт — ключевой:

— Clojure идеально подходит для соло проектов и достаточно плохо подходит для командной разработки.

Именно из-за особенностей влияния среды на командную работу, в Echo на серверной стороне использует в основном Erlang, и только в тех местах, где активный народ принципиально прётся от какой-то альтернативной технологии (i.e., OCaml, Clojure) написано на них.

Tags:

Выдвигаю предложения по усовершенствованию синтаксиса языка JavaScript.

Для примера разберём такую простую конструкцию, как функция, генерирующая замыкания.

function foo(filter, pattern) {
    var f = function(list) { return filter(pattern, list); };
    return f;
};

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

Tags:

Подсыплю ложку первоклассного дёгтя.

Слышали про Сколковский/Казанско-IT-парковский проект распознавания речи при помощи, в том числе, информации о движении губ с видеокамеры?

http://realspeaker.net/ru/

Они получили 9 миллионов финансирования, etc.

Что представляет собой проект? Это программа, которая комбинирует готовые открытые библиотеки распознавания лиц из проекта OpenCV/Emgu.CV (Open Computer Vision) и готового же онлайнового гугл-сервиса по распознаванию аудио (Google Speech Recognition API — то же самое, что происходит при распознавании речи в каждом Андроиде, ровно то, что уже доступно каждому JavaScript-программисту в браузере Chrome, и ровно то, на основе чего мы с sidentdv за одну ночь на ульяновском хакатоне написали проект AudioSMS).

Как комбинирует? Берёт аудио с микрофона и по сети посылает в гугл API, пока губы движутся, и не посылает, пока губы не движутся. Эта зависимость от движения губ называется «детекцией пауз». Сервер гугла в ответ присылает в текстовом виде распознанный текст.

Почему это не прорыв? Потому что если не обладать возможностью действительно встроиться в алгоритмы распознавания аудио, нельзя сделать глубокий фидбэк видео от губ. Например, подмешать видеопоток в bayesian language model. То есть, нельзя сделать так, чтобы губы действительно влияли на качество распознавания аудио. Максимум что можно сделать — вот это самое распознавание пауз, при котором шум с микрофона не посылается в гугл.

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

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

Ещё интересно, что вся информация, которую я написал, доступна в интервью и в описаниях почти прямым текстом. Но когда чиновники хвалятся этим проектом, то создаётся впечатление неокосмических технологий и искусственного интеллекта, который читает прямо по губам.
Вы наверняка уже знаете, что известнейшая Khan Academy, являющаяся пионером по онлайн-образованию школьников, совсем недавно выпустила интерактивные курсы по программированию. В качестве платформы используется JavaScript и библиотека Processing. Вполне логичный и достойный выбор, всячески поддерживаем и одобряем. JavaScript очень даже неплох в качестве первого языка программирования, да и потом в жизни почти каждого инженера он тем или иным образом пригодится. В нашей компании JavaScript вообще является основой бизнеса, ибо «Продукт есть интерфейс».



Брет Виктор — исследователь и визионарий новых интерфейсов человеко-машинного взаимодействия. Я уже писал о нём в моей заметке «Интерфейсы и инструменты»:
Программистам и дизайнерам интерфейсов посвящается. Настолько мощная презентация от изобретателя новых концепций пользовательского интерфейса в Apple, что одним ретвитом @stevebest не обойдёшься.

Так вот, этот самый Брет Виктор сказал, что этот Хан-Академийский интерфейс для обучения программированию — фуфло и туфта.



А так как Брет человек дела, а не только слова, то он написал не просто аргументированную критику связки JS+Processing, использующуюся в курсах Khan Academy, но и потрудился тщательнейшим образом реконструировать возможный интерфейс правильной системы для обучения. Эта работа Брета показалась мне настолько увлекательной, что в голове постоянно крутятся слова seminal paper в применении к данной работе. Это действительно работа мастера. Всем программистам и дизайнерам интерфейсов читать полностью, без вариантов и отмазок.

Читаем: Learnable Programming


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



Ближе к концу Брет отвлекается от проектирования надстройки над JavaScript, и делится видением по поводу метафор, стоящих за языками программирования.
Каждый язык программирования наполнен метафорами, но некоторые ложатся на мозг лучше, чем другие. Стандартный императивный подход использует метафору «присвоение переменным» — перемещение битов между маленькими коробочками. В отличие от черепашки Logo, эта метафора не была спроектирована для того, чтобы соответствовать тому, как люди учатся и понимают; она просто эволюционировала как тонкий слой над метафорами, использующимися в архитектуре низлежащей машины, такими как «сохранение в памяти».*

* Алан Кей в «The Early History of Smalltalk»: «Операторы присваивания — даже абстрактные — выражают очень низкоуровневые цели... Люди-программисты не являются машинами Тьюринга, и чем меньше их программные системы требуют техники от Тьюринг-машин, тем лучше.»

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

Из дальнейшего рассмотрения метафор, на которых построены некоторые другие языки программирования, мы видим, что Smalltalk (или тот же Erlang, если читать между строк) предоставляют очень вкусную метафору посылки сообщений между объектами. «Эта очень мощная метафора, потому что ролевые игры и разговоры являются мощными встроенными человеческими свойствами.»

Далее Брет Виктор цитирует одного из авторов языка Haskell:
Когда программист пишет модульную программу для решения задачи, он сначала разбивает задачу на подзадачи, затем решает подзадачи, и в конце концов объединяет решения. Способы, которыми программист может разбить оригинальную проблему, напрямую зависят от способов, которыми он сможет затем склеить решения вместе. Следовательно, для увеличения чьей-то способности модуляризировать задачи в принципе, нужно обеспечить новые типы клея в языках программирования.

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

Что касается среды Processing (изначально это библиотека для облегчения программирования графики для Java, но теперь доступна и на JavaScript, именно её использует Khan Academy):
Недостатки модульности среды Processing являются серьёзными барьерами для рекомпозиции. Программист не может просто взять у друга модель прыгающего мячика и положить рядом его собственного прыгающего мячика. Переменные должны быть переименованы или инкапсулированы вручную, соответствующие функции "draw" и работа с мышью должны быть переплетены друг с другом, и так далее. Можно легко начать работать с существующей программой Processing и изменять её, но язык не поощряет комбинирование двух программ.

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

Кстати, приводится непрямой аргумент в защиту Objective-C, который я люблю защищать именно из за этого свойства readability для новичков. В цитате ниже мысленно подставьте Objective-C вместо Smalltalk, синтаксис похожий там.
Smalltalk:canvas drawEllipseCenteredAtX:50 y:50 width:100 height:100.
Processing:ellipse(50,50,100,100);
x86 assembly:push 100; push 100; push 50; push 50; call _ellipse

В Smalltalk аргументы дают контекст. В Processing функция "ellipse" точно такая же таинственная, как и в языке ассемблера. Читатель должен подсмотреть или запомнить каждый аргумент — существенный барьер для чтения.

Для того, чтобы освободить меня от необходимости переводить и цитировать — идите и читайте сами :)

http://worrydream.com/LearnableProgramming/

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

P.S. Мы в Echo (aboutecho.com, echorussia.ru) очень сильно хайрим JavaScript-программистов в Ульяновск и Новосибирск. jobs@aboutecho.com

Profile

lionet
Lev Walkin
Website

Latest Month

December 2016
S M T W T F S
    123
45678910
11121314151617
18192021222324
25262728293031

Syndicate

RSS Atom
Powered by LiveJournal.com
Designed by yoksel