Поправьте, если я ошибаюсь, но на DivX в свое время тоже действовали патенты. Тем не менее, его возможности были очень сильно востребованы, в итоге кодек получил широчайшее распространение. Видимо всем хватает обычного JPEG, а jpeg2k не так уж сильно его превосходит.
Инструмент выбирает компетентный человек (кажется, таких называют software architect), причем после того, как будет более-менее прикинут фронт работ. С менеджера станется ляпнуть: «Мы будем писать сервис по поиску простых чисел на пи-эйч-пи, потому что его все знают и писать на нем быстро и легко». Конечно, в стартапах встречаются менеджеры-архитекторы-программисты-дизайнеры-маркетологи, но чем крупнее компания, тем меньше там таких универсалов (в процентном соотношении).
Пока не вижу возможных проблем с использованием Java.
Первое, что приходит на ум: низкая производительность операций с плавающей точкой; борьба в gc за память (вспоминаем, как при знакомстве с Java нам рассказывают, почему для сложения строк придумали StringBuffer); отсутствие поддержки OpenMP (запустить 8 воркеров на 8-ядерной машине и утверждать, что «будет не хуже, чем с OpenMP» — ересь).
Я бы такое применение JVM рассматривал разве что «for fun» или «на курсовую».
SolveMedia уверяет, что делает хорошее дело и помогает человечеству. Они объясняют это так: сейчас люди заполняют в интернете примерно 280 млн «капчей» в сутки на различных сайтах. В среднем заполнение каждой занимает 14 секунд, потому что текст трудно читается. В новых рекламных баннерах текст легко читается и его легко написать, так что в среднем ввод текста занимает 7 секунд. Таким образом, говорят руководители SolveMedia, если заменить все «капчи» в интернете на их рекламу, то люди на планете будут экономить 62 года времени ежедневно.
А, то есть SolveMedia наивно полагают, что капчи такие вот неразборчивые, потому что сделать разборчивую очень сложно? Я, конечно, знал, что у маркетологов с соображалкой туго, но не думал, что настолько.
Мне видится два сценария: 1. спамеры создают свои сайты, на которых сами же устанавливают и разгадывают «денежную капчу»; 2. владельцы сайтов платят спамерам за каждую правильно разгаданную капчу по 2 цента. Самое смешное, что при любом исходе конечный пользователь утопает в лавинах спама.
Как некурящий, считаю запрет на курение на рабочем месте очень здравой идеей.
А вот все эти «тимбилдинги» — бредятина чистой воды, особенно с учетом того, что в России есть тенденция проводить их в нерабочее время с обязательной явкой. И вообще, как наемный работник я заинтересован в достойной оплате своего труда и комфортном рабочем месте. Мягкие игрушки и прочая бредятина в офисе мне до лампочки.
В линукс многие оконные менеджеры давно уже умеют скрывать декорации окон, ориентируясь на имя и класс окна. По-моему, это гораздо более правильный подход. В итоге полоса меню будет не «на месте заголовка окна», а «вместо заголовка окна».
Опережая вопросы о том, как перемещать/изменять размеры такого окошка: зажимаем Alt + левая кнопка +drag — перетаскивание, Alt + средняя кнопка + drag — изменение размеров.
Я прочитал как-то «On Lisp», проникся лиспом и в конце-концов через cliki.net пришел к ucw и решил его попробовать. hello world'ы работали, но с течением времени ucw вдруг начинал потреблять все ресурсы CPU. Я помножил это на откровенный дефицит библиотек в CL и пришел к выводу, что если сильно захотеть, можно написать веб-приложение в Common Lisp, однако преимущества неочевидны, а граблей целое минное поле.
Вводная статья не раскрывает ни тему преимущества CL для веба, ни тему обхода граблей.
О мощности строить программу, о которой ничего не известно на этапе компиляции. Прислушайтесь к моему пожеланию)).
А теперь давайте подумаем: исходный код программы — это текст. Генерировать текст можно в любом практически применимом ЯП. В интерпретируемых ЯП обычно есть eval, которым можно выполнить текст программы. LISP's eval не превзошел в этом контексте ни одного интерпретируемого языка.
Если речь идет о компилируемых языках, можно в самом плохом случае вызвать компилятор, получить shared library из сгенерированного исходного текста, загрузить ее и вызвать оттуда функцию. При этом, кстати, функция будет выполняться быстрее, чем простым eval'ом. Получается, что eval можно сэмулировать даже в компилируемых языках.
Кстати, вот в таких вот отeval'енных функциях нет оптимизации хвостовой рекурсии, которая является достаточно популярным приемом в LISP. Вывод: eval — зло (про compile я знаю если что).
Прислушайтесь к моему пожеланию)).
О «совершенствовании в личностном плане»? То есть, видя откровенно кривой tutorial, я должен писать: «Молодец, так держать! Yes we can!»? Сюсюкаются только с маленькими детьми. Взрослые люди должны адекватно воспринимать конструктивную критику и аргументированно отстаивать свою точку зрения. Будьте добры, аргументированно разрешите противоречия между двумя вашими же тезисами:
1. (defun set-sum-of-n (n) ...) (далее идет текст функции, о которой в compile-time известно, что она генерирует функцию, суммируюущю n чисел)
2. Данным примером я хотел показать возможность LISP'а строить программу, о которой ничего не известно на этапе компиляции.
Если вы не видите противоречий в этих высказываниях, подсказываю: в примере жестко задается вид функции в compile-time и жестко задается список аргументов при ее вызове. При том, что n задается в runtime, а в compile-time пишется вызов с тремя параметрами… Кхм, нулевая применимость за пределами REPL. Уж как минимум следовало бы использовать apply.
Что?! «Мощность eval»? Уважаемый, скажите мне, а eval имеет доступ к compile-time вычислениям? Нет. lambda-функция, полученная вот таким вот eval'ом списка будет скомпилирована? Нет.
О какой мощи идет речь? Вот с макросами, я понимаю, можно часть вычислений вынести из runtime в compile time. А eval — это костыль, использование которого является признаком кривой архитектуры приложения (конечно, в одном случае на миллион еспользование eval будет оправдано, но в посте явно не тот случай).
Я же хотел показать изюменку Lisp.
Изюминка LISP — это eval?! Такая изюминка есть практически в каждом интерпретируемом языке. Изюминка лиспа именно в макросах, которые вследствии своих невычисляемых аргументов способны превратить язык в нечто новое, главное этим не злоупотреблять. Макросы позволяют реализовать DSL максимально прозрачно.
Например, можно написать макрос, аналогичный defun, который будет генерировать обертки для вызова удаленных методов. В итоге объявление и вызов удаленного метода выглядят абсолютно прозрачно, чего в других языках крайне проблематично добиться без каких-нибудь внешних rpcgen'ов.
У меня есть сильное сомнение, что человек, который не знает о defmacro, но рассуждает о метапрограммировании, может научить чему-то хорошему. Приведенный в посте пример должен быть написан в духе
(defmacro sum-of-n (n)
(let ((args (loop for i from 1 to n collect (gensym))))
`(lambda (,@args)
(+ ,@args))))
В противном случае это не LISP, а Javascript со скобками.
Первая часть этого обзора будет вводной. Опытные лисперы смогут смело его пропускать.
Первая часть не получилась вводной. Она вообще никакая. На введение в лисп не тянет (тема list processor'а и его регистров car/cdr не раскрыта). На введение в «Лисп в вебе» не тянет, потому что веб не упомянут. Зато зачем-то в лучших традициях идет повествование о метапрограммировании в контексте лямбда-исчисления, причем не через богоугодные макросы, а через пень-колоду под названием eval. Слабовато извращение. Надо было вообще конструировать строку с определением функции, натравливать на нее read и потом eval — было бы еще кошернее.
Перечитал пост дважды, но так и не нашел описания того, что будет, когда вдруг отключится электричество или понадобится ребут по техническим причинам. Получится закат солнца вручную (описанный паттерн «падение двух слейвов») или где-то в дебрях /etc/init.d лежат скрипты, которые заберут нужный снапшот базы из нужного места и развернут ее?
И вообще, оптимизация дисковых операций выглядит так: 1. убеждаемся, что для «горячих» select'ов у нас есть необходимые индексы и при этом их не так много, чтобы они убивали операции insert/update; 2. задействуем головной мозг и избавляемся от лишних запросов (можно использовать memcached). И только после этого, если ничего не помогло, имеет смысл копать «вглубь», перемещать данные в tmpfs и так далее, и тому подобное.
Вот и возьмут на работу вместо вас молодых людей с «горячим сердцем, руками и головой».
«И приговаривал Балда с укоризной: «Не гонялся бы ты, поп, за дешевизной». Как правило, юношей с горящими глазами стремяться заполучить, чтоб сэкономить на тех, кто примерно представляет себе свою объективную цену.
Работа и есть главный мотиватор!
То есть на зарплату пофиг? Или «пофиг в разумных пределах»? Лично я не понимаю таких альтруистических взаимоотношений, когда работник в лепешку готов расшибиться, лишь бы дело сделать. Это как минимум нездорово выглядит, тем более на фоне работодателя, который готов сэкономить на чем угодно, даже на здоровье сотрудника.
И да — каждый день феерия увлекательных задач, которые надо решать (и я уже отнюдь не молодой человек)
Хотелось бы поинтересоваться областью вашей деятельности, в которой так бесконечно много увлекательных задач.
>У вас есть своя квартира — неважно как она вам досталась, но она ваша. Это — одно из самых ОГРОМНЫХ ваших преимуществ по жизни. Вы практически СВОБОДНЫ.
Не понимаю, как можно не имея за спиной стабильного дохода и места проживания бросаться в авантюру с организацией собственного бизнеса. В случае с зарплатой заранее известно, хватит ли денег на аренду жилплощади. Со своим бизнесом же совсем смешно: на начальных этапах он много потребляет и ничего не дает взамен (это на хабре писали). Встает вопрос: «А жить-то где?».
Так что не имея жилья бросаться в авантюры точно не следует, а вот имея хотя бы 500 тыр «на черный день» и свое комфортное жилье, пусть даже и скромной площади, почему бы и не попробовать «поработать на себя»? В крайнем случае выйдет отпуск за свой счет, сдобренный неким ценным опытом.
>Таких людей видно сразу — они не «горят» на работе.
А зачем мне «гореть на работе»? Между наемным работником и работодателем весьма простые материально-денежные отношения: если «горение» адекватно возмещается в денежном эквиваленте и мне нужны деньги, я могу и «погореть». А, извините, «рвать жопу за идею и строчку в резюме» я оставляю молодым людям с горячим сердцем, руками и головой.
Также мне было бы чрезвычайно интересно услышать о способах мотивирования людей, чья работа действительно монотонна: тестеров и разработчиков. Или у разработчика что ни день, то феерия увлекательных задач, а тестеру доставляет выполнять монотонные однообразные действия по поиску ошибок?
>А так — в наемном труде нет ничего плохого конечно же. Должен же кто-то работать «на дядю» :)
Мне по-прежнему непонятен негативный оттенок во фразе «работать на дядю». Или негативно-пренебрежительный оттенок мне только кажется?
Это издевательство над демосценой. В далеких 90-х демки выжимали максимум из железа и оставалось только сказать «вау!». Смотреть, как подобная примитивщина тормозит на современных процессорах и поминать демосцену как минимум кощунственно.
Первое, что приходит на ум: низкая производительность операций с плавающей точкой; борьба в gc за память (вспоминаем, как при знакомстве с Java нам рассказывают, почему для сложения строк придумали StringBuffer); отсутствие поддержки OpenMP (запустить 8 воркеров на 8-ядерной машине и утверждать, что «будет не хуже, чем с OpenMP» — ересь).
Я бы такое применение JVM рассматривал разве что «for fun» или «на курсовую».
А, то есть SolveMedia наивно полагают, что капчи такие вот неразборчивые, потому что сделать разборчивую очень сложно? Я, конечно, знал, что у маркетологов с соображалкой туго, но не думал, что настолько.
Мне видится два сценария: 1. спамеры создают свои сайты, на которых сами же устанавливают и разгадывают «денежную капчу»; 2. владельцы сайтов платят спамерам за каждую правильно разгаданную капчу по 2 цента. Самое смешное, что при любом исходе конечный пользователь утопает в лавинах спама.
А вот все эти «тимбилдинги» — бредятина чистой воды, особенно с учетом того, что в России есть тенденция проводить их в нерабочее время с обязательной явкой. И вообще, как наемный работник я заинтересован в достойной оплате своего труда и комфортном рабочем месте. Мягкие игрушки и прочая бредятина в офисе мне до лампочки.
Опережая вопросы о том, как перемещать/изменять размеры такого окошка: зажимаем Alt + левая кнопка +drag — перетаскивание, Alt + средняя кнопка + drag — изменение размеров.
Я прочитал как-то «On Lisp», проникся лиспом и в конце-концов через cliki.net пришел к ucw и решил его попробовать. hello world'ы работали, но с течением времени ucw вдруг начинал потреблять все ресурсы CPU. Я помножил это на откровенный дефицит библиотек в CL и пришел к выводу, что если сильно захотеть, можно написать веб-приложение в Common Lisp, однако преимущества неочевидны, а граблей целое минное поле.
Вводная статья не раскрывает ни тему преимущества CL для веба, ни тему обхода граблей.
А теперь давайте подумаем: исходный код программы — это текст. Генерировать текст можно в любом практически применимом ЯП. В интерпретируемых ЯП обычно есть eval, которым можно выполнить текст программы. LISP's eval не превзошел в этом контексте ни одного интерпретируемого языка.
Если речь идет о компилируемых языках, можно в самом плохом случае вызвать компилятор, получить shared library из сгенерированного исходного текста, загрузить ее и вызвать оттуда функцию. При этом, кстати, функция будет выполняться быстрее, чем простым eval'ом. Получается, что eval можно сэмулировать даже в компилируемых языках.
Кстати, вот в таких вот отeval'енных функциях нет оптимизации хвостовой рекурсии, которая является достаточно популярным приемом в LISP. Вывод: eval — зло (про compile я знаю если что).
О «совершенствовании в личностном плане»? То есть, видя откровенно кривой tutorial, я должен писать: «Молодец, так держать! Yes we can!»? Сюсюкаются только с маленькими детьми. Взрослые люди должны адекватно воспринимать конструктивную критику и аргументированно отстаивать свою точку зрения. Будьте добры, аргументированно разрешите противоречия между двумя вашими же тезисами:
1. (defun set-sum-of-n (n) ...) (далее идет текст функции, о которой в compile-time известно, что она генерирует функцию, суммируюущю n чисел)
2. Данным примером я хотел показать возможность LISP'а строить программу, о которой ничего не известно на этапе компиляции.
Если вы не видите противоречий в этих высказываниях, подсказываю: в примере жестко задается вид функции в compile-time и жестко задается список аргументов при ее вызове. При том, что n задается в runtime, а в compile-time пишется вызов с тремя параметрами… Кхм, нулевая применимость за пределами REPL. Уж как минимум следовало бы использовать apply.
Что?! «Мощность eval»? Уважаемый, скажите мне, а eval имеет доступ к compile-time вычислениям? Нет. lambda-функция, полученная вот таким вот eval'ом списка будет скомпилирована? Нет.
О какой мощи идет речь? Вот с макросами, я понимаю, можно часть вычислений вынести из runtime в compile time. А eval — это костыль, использование которого является признаком кривой архитектуры приложения (конечно, в одном случае на миллион еспользование eval будет оправдано, но в посте явно не тот случай).
Изюминка LISP — это eval?! Такая изюминка есть практически в каждом интерпретируемом языке. Изюминка лиспа именно в макросах, которые вследствии своих невычисляемых аргументов способны превратить язык в нечто новое, главное этим не злоупотреблять. Макросы позволяют реализовать DSL максимально прозрачно.
Например, можно написать макрос, аналогичный defun, который будет генерировать обертки для вызова удаленных методов. В итоге объявление и вызов удаленного метода выглядят абсолютно прозрачно, чего в других языках крайне проблематично добиться без каких-нибудь внешних rpcgen'ов.
В противном случае это не LISP, а Javascript со скобками.
Первая часть не получилась вводной. Она вообще никакая. На введение в лисп не тянет (тема list processor'а и его регистров car/cdr не раскрыта). На введение в «Лисп в вебе» не тянет, потому что веб не упомянут. Зато зачем-то в лучших традициях идет повествование о метапрограммировании в контексте лямбда-исчисления, причем не через богоугодные макросы, а через пень-колоду под названием eval. Слабовато извращение. Надо было вообще конструировать строку с определением функции, натравливать на нее read и потом eval — было бы еще кошернее.
Извините, но жирный низачот.
И вообще, оптимизация дисковых операций выглядит так: 1. убеждаемся, что для «горячих» select'ов у нас есть необходимые индексы и при этом их не так много, чтобы они убивали операции insert/update; 2. задействуем головной мозг и избавляемся от лишних запросов (можно использовать memcached). И только после этого, если ничего не помогло, имеет смысл копать «вглубь», перемещать данные в tmpfs и так далее, и тому подобное.
«И приговаривал Балда с укоризной: «Не гонялся бы ты, поп, за дешевизной». Как правило, юношей с горящими глазами стремяться заполучить, чтоб сэкономить на тех, кто примерно представляет себе свою объективную цену.
То есть на зарплату пофиг? Или «пофиг в разумных пределах»? Лично я не понимаю таких альтруистических взаимоотношений, когда работник в лепешку готов расшибиться, лишь бы дело сделать. Это как минимум нездорово выглядит, тем более на фоне работодателя, который готов сэкономить на чем угодно, даже на здоровье сотрудника.
Хотелось бы поинтересоваться областью вашей деятельности, в которой так бесконечно много увлекательных задач.
Не понимаю, как можно не имея за спиной стабильного дохода и места проживания бросаться в авантюру с организацией собственного бизнеса. В случае с зарплатой заранее известно, хватит ли денег на аренду жилплощади. Со своим бизнесом же совсем смешно: на начальных этапах он много потребляет и ничего не дает взамен (это на хабре писали). Встает вопрос: «А жить-то где?».
Так что не имея жилья бросаться в авантюры точно не следует, а вот имея хотя бы 500 тыр «на черный день» и свое комфортное жилье, пусть даже и скромной площади, почему бы и не попробовать «поработать на себя»? В крайнем случае выйдет отпуск за свой счет, сдобренный неким ценным опытом.
>Таких людей видно сразу — они не «горят» на работе.
А зачем мне «гореть на работе»? Между наемным работником и работодателем весьма простые материально-денежные отношения: если «горение» адекватно возмещается в денежном эквиваленте и мне нужны деньги, я могу и «погореть». А, извините, «рвать жопу за идею и строчку в резюме» я оставляю молодым людям с горячим сердцем, руками и головой.
Также мне было бы чрезвычайно интересно услышать о способах мотивирования людей, чья работа действительно монотонна: тестеров и разработчиков. Или у разработчика что ни день, то феерия увлекательных задач, а тестеру доставляет выполнять монотонные однообразные действия по поиску ошибок?
>А так — в наемном труде нет ничего плохого конечно же. Должен же кто-то работать «на дядю» :)
Мне по-прежнему непонятен негативный оттенок во фразе «работать на дядю». Или негативно-пренебрежительный оттенок мне только кажется?
Добро пожаловать в World-2.0, что еще скажешь!