Программирование в стиле Теремка

[@Ghostwriter]

Автор имеет дело только с объемами, целиком помещающимися в один сервер?

[@ddosia]

все фигня, кроме пчёл

[@vsviridov]

Но если подумать — то пчёлы тоже фигня…

[@Britannic]

Все фигня кроме того, что не фигня

[@maashaa]

> один сервер
у меня было 50 нод и xargs -n1 | ssh работало`get_free_server` sh -e$- build_test.sh

а ещё в одной известной компании, которую купил Oracle, все файлы (включая все версии всех дистрибутивов) лежали в /

[@myas]

> Конечно, понадобится Hadoop MapReduce
> Буэ, к чертям эту ерунду:
> find crawl_dir/ -type f -print0 | xargs -n1 -0 -P32 ./process
Экскаватор? Буэ, к чертям эту ерунду: десяток гастарбайтеров с лопатами! На самом деле, я доверяю лопате больше чем самому себе!

[@CheatEx]

Hadoop мягко говоря не готовый экскаватор.

[@myas]

к лопате тоже мягко говоря тоже нужны гастарбайтеры (hint: ./process)

[@CheatEx]

Гастарбайтеры, а не квалифицированные слесари, прошедшие переподготовку под конкретные станки.

[@myas]

Вы, видимо, не совсем правильно понимаете посыл моего первого комментария. Тот факт, что инструменты надо выбирать под стать задаче не вызывают сомнений, но иллюстрации, на мой взгляд совершенно дикие. Mapreduce не имеет смысла на одной машине, xargs же на кластере порождает проблем больше чем решает. Как их вообще можно сравнивать? Копать червей эксаватором никому в голову не приходит, так же как и прокладывать канализацию гастарбайтерами с лопатами. Вы же говорите что лопаты лучше потому что к ним не нужен специально обученный экскаваторищик. Путаница тёплого с мягким.

[@mikhanoid]

Распределённый Map-Reduce пишется на Bash (если в системе установлен ssh) в 10 строчек.

[@myas]

(пожимает плечами)
я очень сомневаюсь, что это будет хотя-бы удалённо напомитать хадуповский мапредьюс.

[@mikhanoid]

В смысле? map-reduce — это определённый алгоритм, с определённой семантикой. Можно реализовать именно этот алгоритм. Что означает: «он будет напоминать хадуповский»?

[@myas]

ну хадуп это же фреймворк для выполнения mapreduce задач, который берёт на себя решения ряда проблем, возникающих при кластерных вычислениях, таких как доставка данных до процесса, выполнение задач (по возможнсти) близко к данным, сортировка промежуточных результатов, перезапус задачи при неудаче etc. Ваш bash-скрипт на 10 строчек тоже это будет уметь?

[@Eternalko]

Начали за здравие, кончили за упокой.
Спор о двух методах решается через убеждение внутри метафоры (:

Как в детстве.
— Кто круче. Вандам или Шварц?
— Давай я Шварц, а ты Вандам и посмотрим кто кого!

[@CheatEx]

Этот метод гораздо точнее отражает реальность, чем может показаться на первый взгляд.

[@andy128k]

Однажды Мастер Фу сказал заезжему программисту: «В одной строке кода shell-сценария больше духа UNIX, чем в десяти тысячах строк на языке С!»
…

[@lymes]

Автор имеет в виду, что среди множества сложных технологий с громкими названиями и большими возможностями, иногда мы забываем о простых старых инструментах, которыми некоторые задачи решаются просто и быстро.
Повторю на всякий случай: ИНОГДА.
Иногда это происходит из-за банального незнания базовых утилит UNIX. Обычно этим страдает молодежь, которая не боясь сложностей, засучив рукава и подшаркивая от нетерпения ножкой начинает лезть в дебри сложнейших платформ. Олдфаги ленивее и знают, что иногда проще написать, запустить скрипт и пойти пить кофе.

[@tangro]

Прикольно, конечно, пользоваться такими вещами для задач «найти что-то на миллионе веб-страниц». А попробуйте с таким подходом написать БД, ОС, компилятор или драйвер. Да чего там — приложение для мобильных систем или корпоративный портал. Ничего не выйдет. Потому что для забивания гвоздей подходит и штатный молоток, а вот бозон Хиггса без андронного коллайдера не найти.

[@silvansky]

Зато можно двумя-тремя строчками, написанными за 2 минуты, сделать то, на что у несведующего ушло бы 83+ строк на C/C++/etc, два дня отладки и день тестирования. И будет это эффективнее и надёжнее. Но это — не панацея, разумеется, и к мобильным разработкам это отношения не имеет, равно как к ОС и БД. Всякой задаче да будет подходящий инструмент.

[@Tagire]

Для компиляторов часто используется yacc+bison, для ОС часто используют готовые куски(POSIX слой BSD в MacOS, linux ядро в Android).
В исходниках того же питона 20 тысяч строк на bash, в исходниках posgresql их 30 тысяч, в исходниках mysql их 70 тысяч. Простые утилиты используются во многих местах.

[@tangro]

что-то я туплю, простите. Что делают все эти десятки тысяч строк в кросс-платформенных проектах? Как оно работает на той же Винде? Там для Винды отдельный код на С/С++? Тогда в чём смысл?

[@amarao]

На этапе сборки.

[@Tagire]

В основном для системы сборки или работы с тестами. Для сборки приложений на винде часто бывает нужно отдельно скачивать эти утилиты скомпилированные под винду.
Хотя для постгреса там под винду написали свою систему сборки на небольшом количестве батников и большом количестве перла. Но она попроще, чем под остальные ОС.

[@vilgeforce]

«С такой простой периодической таблицей элементов» — где авторр узрел таблицу и уж тем более периодичность в ней — для меня остается загадкой :-)

[@silvansky]

Кстати, почему ненормальное-то? Это, на мой взгляд, вполне нормальное программирование. По сути, это то же, что сказать новичку «зачем писать БД с нуля, если есть %DBNAME%?» Я, кстати, в самом начале своего пути программиста был бы благодарен за такое восклицание, и не стал бы писать весь тот ужас свою БД.

[@ainu]

Немного из этой темы — на регулярках можно сделать очень многое, часто включая то, для чего регулярки вроде и не нужны.

[@SonicGD]

You have a problem… you decide to use regular expressions… now you have two problems :-)

[@burjui]

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

[@SonicGD]

В общем то это шутка была

[@vaevictus]

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

Если бездумно пытатся решить задачу стандартными решениями — то напоретесь на «изменить вот эту маленькую ерунду» — в результате которой прийдётся таки сделать свой велосепед

[@Sannis]

Туту как раз вопрос в том, какие из ставших стандартными решений выбирать :)

[@coocheenin]

Немножко спутанны понятия программиста (человека решающего задачу, путём написания кода на неком языке программирования) и devolopment-leader-а, архитектора — человека выбирающего иснтрумент, с помощью которого будет решаться задача (хотя в небольших компаниях, фрилансе это часто один и тот же человек).

Почему бы не назвать его «ведущим разработчиком» вместо «devolopment-leader»?
И нет, я не граммар-наци ;)

С одной стороны вы несомненно правы, с другой — только в теории. В наших реалиях большинство компаний являются «небольшими» и поэтому спутанность понятий является скорее тождественностью.

[@coocheenin]

Упс. Промахнулся, предназначалось в ответ на habrahabr.ru/blogs/crazydev/133697/#comment_4438132

[@anarleen]

и изменил лишь название компании, которая используется как пример

Ну зачем, зачем переводчики постоянно это делают? Зачем Facebook превращать во «ВКонтакте», Starbucks в «Кофе Хауз», Google в Яндекс, спагетти в доширак, а сигары в самокрутки и вообще заменять любое оригинальное понятие на его российскую «локализацию»?

Разве нельзя просто дать ссылку на то, что такое Taco Bell? Неужто здесь такая дремучая глубинка, а не общество, идущее к глобализации и интернационализации?

[@arraen]

Мне например как жителю Украины вообще не понятно что это за Теремок и причем он тут. А что такое Тако Бэл я знаю.

[@SonicGD]

Я вроде из России, а Теремок всё равно не знаю.

[@rg_software]

Согласен, но чёрт поймёт, что лучше. Taco bell — не Гугл, а локальная американская контора, я её больше нигде не видел, интернационализация и глобализация здесь не при чём :)

[@Eltaron]

И в фильмах-сериалах никогда не видели, и в книжках американских авторов не встречалась?
Мне вот тоже вся эта локализация жутко не нравится.
Знаете, в Чехии «Алису в стране чудес» Кэррола перевели в свое время как «Аленка в стране чудес», видимо, имя Алиса чуждо чешскому уху. И даже сейчас, через 150 лет, чехам пришлось идти на поводу у не очень дальновидного переводчика, и переводить недавний фильм Бёртона тоже как «Аленка...».

[@rg_software]

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

У нас Алиса в стране Чудес тоже изначально вышла как «Соня в царстве Дива».
Сейчас да, Алиса и да, в стране Чудес.
А вот Jabberwocky как назвали Бармаглотом, так до сих пор и есть.

Это тонкий момент, скажем, в Финляндии до сих пор имена адаптируют к местному языку.

[@Eltaron]

Ну, в Финляндии все называется по-своему, там даже общечеловеческого, казалось бы, слова «компьютер» нету :) А в русском языке наоборот, очень много заимствований. Поэтому и подход к переводу должен быть разным.
Американизация-не американизация, но Taco Bell — это хоть и локальный бренд, но он такой же известный, как какой-нибудь Wal-Mart.

[@Ogra]

Владимир Набоков перевел Алису как «Аню». Но у нас не прижилось, и хорошо ;)

[@kirilloid]

Ну, в России встречается имя Алиса. Хотя все Алисы, которых я знаю, родились после 80-го.

[@artem_dev]

а еще Набоков перевел Алису как Аню, но к счатью его вариант не прижился :)

[@stoune]

Вы наверное имели ввиду всё таки SOA а не SOAP?

А насчёт Hadoop я посмотрю как вы скажем 3-4 Петабайта будете обрабатывать. Есть разные задачи и под них есть свой инструмент. Для простого анализа и sed может хватить, а для полноценной класификации кластеризации разрозненых данных приходится строить звездолёт, потому что sed-а мало.

[@angry_elf]

Всё так и есть.

[@tzong]

А как же освоение бюджета???

[@EvilShadow]

Что такое Теремок и что за люди на картинке?

[@fisher]

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

[@EvilShadow]

Ну кто-то из этих семи не слышал про Теремок. Что это, всё-таки?

[@fisher]

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

[@make_luv]

Да это же Рауль Дюк в пожилом возрасте.
Теремок — сеть забегаловок с блинами.

[@SLY_G]

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

[@egorinsk]

Если задача — скачать миллион страниц из составленного заранее списка (ага, а кто интересно его составит?), то да, проще сделать wget. Но на реальных задачах (клиенту нужна система автоматизации чего-нибудь) bash бесполезен на 100%. Shell-скрипт — это лишь средство для управлени сервером\выполнения рутинных задач и не более.

Статья — бред, короче.

[@philpirj]

Вот тут прогуляйтесь по ссылкам в начале поста, да и сам пост.

[@amarao]

xargs многопоточный???? Чьёрт, где вы были раньше?

Спасибо.

[@amarao]

В саааамом низу. Подло.

[@amarao]

(find /usr/share/man/man* |xargs -n 1 -P 4 gzip -dc) |wc
1531851 7560488 48918016

48 мегабайт текста. Полтора миллиона строк. Читали ли вы их все?

[@amarao]

Я не могу предпочитать xargs, например, ls, tar, gzip, и т.д. у которых примерно такого же размера маны, так что прочитать их все целиком (и помнить) — явно тяжко. Хотя и полезно, да.

[@powerman]

Всё описанное в статье верно и здраво, но только до тех пор, пока речь идёт об одноразовых задачах. Как только становится вопрос поддержки этого кода, надёжности, etc. — сразу возникает куча вспомогательных подзадач: логи, контроль ошибок, восстановление после ошибок (напр. перевыкачка через некоторое время не скачавшихся станичек или информирование админа о сбоях скрипта ./process при обработке некоторых страниц). Реализация всего этого в том же «наколеночном» стиле хоть и возможна, но крайне неудобна в реализации во-первых, и в поддержке во-вторых. Как только становятся вопросы производительности, начинаются аналогичные проблемы: запускать отдельный процесс для обработки каждой странички весьма накладно, особенно учитывая что страничек миллионы, а процесс это очередной скрипт (который нужно распарсить, проинтерпретировать и выполнить); кроме того как уже выше упоминали, не всё можно проделать на одном сервере.

[@philpirj]

Хочется отметить, что syslog поддерживает различные варианты нотификации, в том числе и по почте. По поводу отдельного процесса для каждой страницы — в примере xargs ограничивает количество процессов 32мя. Если страничка не скачивается wget по умолчанию 20 раз повторяет попытки.

[@powerman]

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

Конкретнее: нотификации syslog по почте это круто, но это ведь придётся настраивать в настройках syslog, а не нашего скрипта, что заметно усложняет установку и поддержку скрипта; xargs -P насколько я помню ограничивает кол-во одновременно запущенных процессов, но в любом случае он будет запускать новый процесс для обработки каждой странички, т.е. в конечном счёте процессов придётся таки запустить миллионы; wget повторяет все свои попытки одну за другой, а обычно если сервер не отвечает прямо сейчас, то требуется попытаться снова через некоторый интервал (пол часа/час/день).

[@philpirj]

Нотификация по почте включается по умолчанию в syslog при установке postfix.
Не понимаю накладности запуска процессов в контексте операции, включающей ввод-вывод, которая сама по себе куда затратнее. Предложите хороший вариант, который ограничивается количеством процессов равным количеству процессоров, интересно.
Можно настроить карусель из файлов при скачивании для повторения попытки, когда остальные будут пройдены. И нет особого смысла писать это на чём-то кроме шелл скрипта.

[@powerman]

Нотификация по почте включается по умолчанию в syslog при установке postfix.

Я имел в виду ситуацию, когда в процессе работы приложения возникает ошибка, которая обычно возникать не должна. Обычно в таких случаях не ограничиваются записью ошибки в лог, а отправляют письмо админу или разработчику. (По крайней мере это «обычно» для приложений, которые работают в фоне 24x7 или как минимум часами — вроде анализатора миллионов вебстраничек.) В этом случае, кто-то должен где-то в syslog настроить, что при записи в лог определённого сообщения нужно продубировать его на определённый email. Эта настройка специфична для конкретного скрипта, но делается вне этого скрипта, т.е. мы получаем «размазывание» настроек нашего скрипта по нескольким местам, что усложняет его установку и поддержку.

Не понимаю накладности запуска процессов в контексте операции, включающей ввод-вывод

А Вы померяйте. Простой пример: скрипт считывает 60KB html-ку, находит в ней title и выводит его на stdout. Этот скрипт отрабатывает за 0.002 сек. И почти всё это время уходит именно на запуск скрипта, а не на считывание им html-ки и работу регулярного выражения в поисках title. Это легко увидеть, сравнив запуск этого скрипта напрямую, и через дополнительный exec() — а-ля time ./process и time sh -c ./process — второй вариант займёт почти 0.004 сек (на моём компе). exec — это довольно дорогая операция. Тем более, что запускается не бинарник, а скрипт — т.е. запуск каждого процесса это не просто exec, а ещё и считывание/разбор/выполнение скрипта.

[@chebureque]

Статья хороша, а вот перевод не очень качественный.

«Нужно написать распределённый паук» — как-то это совсем не по-русски.

[@acidnik]

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