Missing-male

Несколько замечаений. Во-первых, с форумом советую поторопиться, потому что он ОЧЕНЬ нужен. Ругань, разборки и "чат между старыми друзьями" никуда не исчезнут. Убеждение людей никогда не действовало достаточно эффективно. Поэтому нужен механизм контроля. То, что предложил nagual, звучит интересно, но я когда-то участвовал в проекте, где была такая система. В последствие от неё отказались и перешли на систему, когда пользователь с определённым положительным рейтингом автоматически становился модератором и имел возможность удалять сообщения других, непривигилированных пользователей. Звучит ненадёжно, но там это работало и работает по сей день. Однако, это было на форуме, где шло обсуждение. Если хотите чистые отзывы, то "плохие комментарии" лучше сразу удалять, можно при этом ещё автоматически отправлять комментатору личное сообщение с текстом сообщения и предложением перенести его на форум. По-моему, и демократично, и чистоту в комментариях сохранить можно.

Во-вторых, вырезать текст из комментариев, на мой взгляд, очень неправильно. Одно дело, когда вы просто удаляете сообщение, противоречащее правилам, и совсем другое, когда изменяете сам его текст. Это уже папахивает нарушением авторских прав. Посмотрите, к примеру, на livejournal: там модератор может удалить пост, но как-либо менять содержимое он не может. Да и задолбаетесь вы править сообщения =)

Missing-male

Чем хороша такая система, так это тем, что она сама себя регулирует: обиженные пользователи могут самостоятельно понизить рейтинг злоумышленникам и, тем самым, лишить их способности удалять сообщения. Ну, если и это не поможет, то всегда можно пожаловаться администрации на нарушителей, а те уже смогут заблокировать их (как по аккаунтам таких "представителей компаний", так и по ip, и даже по MAC'ам их машин).

Missing-male
+1

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

В остальном поддерживаю.

Missing-male

iTransition - структурное подразделение Белхарда, и часто тех, кто пытается туда устроиться, посылают именно на курсы Айтранзишн.

Missing-male
+2

Епам проводит три типа курсов: по Java-технологиям (включая всё веб-программирование, в том числе javascript, xml, sql и всё всё всё), по тестированию Java-продуктов (единственное, что не знаю, так это по ручному или автоматическому) и по .Net-технологиям. В целом уровень подготовки средний (по крайней мере по Java-технологиям, на которых я занимался сам): захватывается много тем, но преподаётся очень поверхностно. Как было правильно замечено выше, там скорее дают книги и другие материалы, а осваивать всё это нужно самостоятельно.

В iTransition, насколько я знаю, курсы немного послабее. Про что-то серьёзное в других компаниях вообще не слышал.

Missing-male
-1

Вообще-то всегда был.

Missing-male

> объясните мне, пожалуйста, связь

А должна быть связь? По-моему, матрица вполне адекватно отражает все области деятельности программиста. У меня, вот, например, есть пункты и с нулями, и с тройками, и в тех областях, где у меня ноль, я объективно чувствую себя неуверенно и на собеседовании предпочёл бы не получать такого вопроса :) С другой стороны, на месте менеджера я бы прогнал кандидата по всей таблице, чтобы точно знать, что от этого человека можно ожидать: возможно, он знает кучу технологий, но при этом абсолютно не умеет декомпозировать задачу и строить уровни абстракции - доверите ему делать архитектуру проекта?

Missing-male

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

Missing-male

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

Missing-male

А вот тут согласен, ибо сам до сих пор понять не могу, почему свойства проекта находятся в меню File, а текстовый редактор пытается то и дело вставить тег < a href.... > вместо того, что мне надо :)

Missing-male
-2

Хм, а что не так с синтаксисом?

Missing-male

Ну а JavaScript, в таком случае - помесь Джавы, Паскаля и Скима, и ничего, пользуется популярностью ;)

Missing-male

Ну ООП языки традиционно как-то не сильно популярны в системном программировании (Sing# не в счёт, там вообще парадигм намешано), а тяга к низкоуровневости вполне логична, если учесть, что гугль хочет этим языком заменить у себя Си.

Missing-male

Видимо, подразумевалась статическая проверка типов в Си в противоположность питоновской динамической типизации. Хотя, ИМХО, использование указателей и goto- горааааздо более опасная вещь, чем определение типа в рантайме :)

Missing-male

http://lib.1024.info/text/author/EdsgerDijkstra/GotoConsideredHarmful.html

Безопасность (корректность выполнения) зависит от степени понимания программистом процессов, происходящих в программе. Один из наиболее используемых и общепринятых способов достижения этого понимания - структурное программирование. goto снижает степень структурированности ПО, следовательно, в общем случае ухудшает понимание, следовательно ухудшает безопасность. Ну это если по теории. На практике уже много раз убеждался, что чем более сложным является control flow, тем чаще программа падает. Причём количество ошибок возрастает экспоненциально.

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

Missing-male

Хм, а что Вы предлагаете? Не изобретать новых языков?

Missing-male

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

Missing-male

И программировать паралелльные процессы на Си?

Missing-male
+1

Прочитал этот пост из Хрома под Убунтой и авторитетно заявляю: глючит :)

С другой стороны, в Хром я залез из-за того, что dev.by перестал узнавать мою лису и авторизовать меня на сайте, так что... :)

Missing-male

Да, вечером постараюсь в личку нормальный репорт написать.

Missing-male
+1

Согласен. Как говорил Стив Круг (на мой взгляд вполне авторитетный эксперт по Юзабилити), "Избавьтесь от половины слов на каждой странице, затем уберите половину того, что осталось". Почему бы не применять это правило и при опубликовании вакансии?

Хотя от суждений на тему собственно требований я, пожалуй, воздержусь. Слишком уж скользкая тема.

Missing-male

Я понял :)

Missing-male

Итого, ответ состоит в том, что нефиг было писать целый фреймворк, а достаточно было написать набор отдельных специализированных библиотек, чтобы потом и Петя мог их легко в свой проект прицепить, и самому Васе в будущих разработках не пришлось бы писать ещё один фреймворк, для решения своих _новых_ задач.

Missing-male

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

Missing-male
+1

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

Missing-male
+1

Я писал длинный длинный комент, но потом нажал "ответить" в другом месте и он пропал, так что в двух словах.

Я вижу в посте 2 темы:

1) программирование стало скучным;

2) фреймворки сакс.

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

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

Missing-male
-1

Я ещё раз скажу: программы не становится проще разрабатывать, наоборот, появляется куча заморочек, куча конфигов и непрозрачных зависимостей. Вы меняете что-то, что по вашему мнению не должно ни на что повлиять - и о-па! Проект уже сваливается при инициализации. Вы хотите поменять одну простую настройку на динамически подставляемое значение, а эта настройка в XML-файле, и динамически её можно поменять только через одно глубокое место. Для примера возьмите какой-нибудь JSF: web.xml, faces-config.xml, замороченная навигация и абсолютно непонятный control-flow. Теги на странице раскрываются в кучу html javascript, ещё и implementation-dependent. Как изменить поведение тега на одной единственной странице? Правильно, написать свой собственный тег, а это ещё куча стаффа и изучения невнятных мануалов по непрозрачной технологии.

Это всё обязательные аттрибуты фреймворка? Да ни разу. Для сравнения возьмите Django: все настройки хранятся в одном файле и представляют собой обычные программные объекты. Запрос попадает в urls.py, оттуда диспатчится в соответствующий views.py, использует возможности template-процессора и возвращает результат. Отображение любого виджета строго определено в документации и может быть легко реализовано на странице вручную. Всё просто и прозрачно. Кто мешал сделать такое в JSF и других джавовских фреймворках? Чем эти фреймворки помогают упростить и ускорить разработку, если всё равно приходится лезть в тонкости работы http-запросов, да к этому ещё и разбираться с тоннами документации самого FW?

Missing-male
+2

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

Missing-male
-1

Гы, целых два человека заминусовали, а высказать своё мнение чё, слабо?))

Missing-male

Надо. Потому что это интересно, как минимум.

Missing-male
+1

Понравилась идея про молоток Маслоу наоборот, но IMO мысль не закончена: автор так и не показал, где и как именно используется математика. А между тем для создания даже простого сайта, при условии его большой посещаемости, ой как не помешает, например, теория массового обслуживнаия. Тем более, если этот сайт - интерфейс для какого-то производственного процесса. Захотели привязать к сайту поиск - а какой именно? полнотекстовый по ключевым словам или сканирующий по подобию? Изучайте алгоритмы поиска. Облако тегов или связанные по смыслу ролики, как на ютюбе, - придётся почитать про семантическую связность слов.

Даже чтобы соптимизировать запросы к БД, полезно знать, во что эти запросы скомпилируются, и как будут обрабатываться.

Другой вопрос, где именно заканчивается математика и начинается программирование :)

Missing-male

А в какой области у Apple монополия? :) MS практически монополно владеет рынком домашних ПК, это понятно, а Apple? Ноутбуки, плееры, телефоны, ОС и т.д. - яблочные везде имеют свою нишу, но нигда не занимают главенствующую позицию, как никак.

Missing-male

http://www.macrumors.com/2010/04/10/steve-jobs-offers-explanation-about-iphone-sdk-changes-restricting-adobe-and-other-cross-compilers/

Jobs reportedly points to John Gruber's analysis of why Apple might have implemented this. Gruber argues that Apple wants control over native iPhone OS development and cross platform solutions would dilute iPhone-exclusive and iPhone native apps.

If that were to happen, there's no lock-in advantage. If, say, a mobile Flash software platform, which encompassed multiple lower-level platforms, running on iPhone, Android, Windows Phone 7, and BlackBerry, were established, that app market would not give people a reason to prefer the iPhone.

....

And, obviously, such a meta-platform would be out of Apple's control. Consider a world where some other company's cross-platform toolkit proved wildly popular. Then Apple releases major new features to iPhone OS, and that other company's toolkit is slow to adopt them. At that point, it's the other company that controls when third-party apps can make use of these features.

___________

К сожалению, не являюсь пользователем продуктов от Apple, поэтому не могу полностью оценить ситуацию. Однако, насколько я понимаю, компания сейчас продолжает делать то, что делала все эти годы: строит свой маленький идеальный мирок. В своё время они отказались открыть стандарты на компоненты своих комьютеров, что позволило им свободно изменять конфигурацию и лучше интегрировать отдельные части. Сейчас они закрывают доступ другим вендорам в сферу ПО, чтобы, опять же, иметь возможность быстро довододить нововведения в своих системах до пользователя, а не ждать, пока какая-то другая компания (в т.ч. Adobe) сможет подстроиться под эти изменения ("and that other company's toolkit is slow to adopt them"). По крайней мере, это выглядит вполне логичным как с точки зрения маркетинга (не отдавать контроль над своей платформой другой компании), так и с точки зрения конечного пользователя (максимальная эффективность за счёт поставок от одного вендора).

А вот как они YouTube будут в iPad'ы засовывать - это действительно интересно.

Missing-male
-2

Вопрос был именно в том, пойдёт ли Google на встречу Apple. Пошёл, и это замечательно, спасибо за разьяснения :)

Missing-male

> Apple has 91% of market for $1,000

> According to NPD, in June, average selling prices for all PCs sold at US retail was $701... For all Windows PCs, ASP was $515 in June. For Macs: $1,400.

То есть Apple лидирует только в продажах компьютеров за $1000+ долларов, в то время, как средняя цена за все проданные машинки - всего лишь 700 у.е. Таким образом, опять же видим стандартную для яблочных ситуацию: они выбрали себе нишу: дорогие высококачественные и высокопроизводительные компьютеры. Ниша не слишком большая (тем более, что процентов 70-80 рынка сбыта не выходит за пределы США), но в ней они действительно легко добиваются успеха. Тем не менее, Apple не делает ничего, чтобы заставить вас купить именно их продукцию: вы покупаете качество, не хотите качество - ваше дело, покупайте Windows PC за $700.

Да, конечно, можно придраться к тому, что Apple отделяет своих пользователей от остальных, запрещая им пользоваться сторонними продуктами типа Flash, но, учитывая количество этих пользователей (MacOS всё ещё стоит всего на 5% PC), их скорее можно обвинить в сектанстве, чем в нарушении антимонопольных законов :)

К слову, про одну область я всё-таки зыбыл: Apple практически монопольно владеет рынком продажи цифровой музыки. И вот там к ним уже давно постучались:

http://brainstormtech.blogs.fortune.cnn.com/2008/01/04/antitrust-apple-charged-with-bullying-microsoft/

Missing-male

Не малобюджетных, а для безработных:

http://www.insideria.com/2009/04/free-flex-builder-for-unemploy.html

To receive the product under this program, you must attest to the fact that you are currently unemployed and that the software will be used only for your personal use not for any production or commercial purposes.

Со студентами то же самое - для обучения пожалуйста, а в коммерческих целях - ненене.

К тому же сейчас Flex/Flash Builder жёстко привязан к Винде, и если вы захотите делать всё по-честному, то придётся платить ещё и за неё и за все несвободные тулзы.

Missing-male

> Чтобы писать и тестить под iPhone надо, по хорошему, купить десктоп яблочный, сам айфон и лицензию для appstore.

iPhone SDK бесплатна и доступна на Windows, Linux и MacOS, цена за "вступление в клуб" - порядка $100. Неа, Flash'ем заниматься дороже :)

Missing-male
-4

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

Ну а если очень хочется официального, то виртуальные машины ещё никто не отменял, как бе.

Missing-male
-2

1. Если этот софт нормально поддерживает все сервисы Apple (в том числе работу с App Store), то почему бы и нет. Если боитесь, что чего-то не хватает, поставьте OSx86 или обычый OS X на VMWare. Я очень сомневаюсь, что из-за пары приложений к вам в дверь постучаться и попросят пройти. Единственный вариант, когда это действительно может случиться, так это в случае серьёзной корпоративной разработки, где всё должно быть официально и по-белому, но в таком случае у вас так или иначе должен быть приличный начальный капитал, и покупка Mac'ов вряд ли станет самой серьёзной статьёй расходов.

2. Опять же, если вы - индивидуальный разработчик, решивший писать софт под iPhone'ы, при этом не имеющий своего MacBook'а (что уже удивительно, потому что непонятно, откуда взялась такая мысль и зачем это вообще тогда сдалось), то не поленитесь, потратьте пару дней на настройку виртуалки и будет вам счастье.

Я хочу сказать, что не надо делать из программирования для Айфонов что-то нереальное. Это делали и делают: официально, не официально, для App Store, для "чёрного рынка"... Просто выберите, по какому именно пути пойдёте конкретно вы. Если захотеть, то всё можно сделать, и не обязательно для этого покупать MacBook и iPhone.

Я писал на Visual Studio под VMWare, на Mono в Emacs, на Delphi (free pascal) под Линуксом, даже почти настроил в нём же Flex SDK (в последний момент отпала необходимость, т.к. достал бесплатно версию Flex Builder для Windows) и на много ещё каком "альтернативном" софте. И ничего, выжил, и даже деньги за свою работу получил.

____________________

К добавленному:

http://www.ihackintosh.com/2009/12/install-snow-leopard-in-vmware-7-windows-edition/

Установка Snow Leopard на VMWare (Windows Host)

http://www.ihackintosh.com/2009/09/install-snow-leopard-106-on-amd-pc-hackintosh/

Установка его же на AMD

http://en.wikipedia.org/wiki/OSx86

Mac OSx86 - неофициальная версия OS X, работающая на x86 процессорах.

http://wiki.osx86project.org/wiki/index.php/Quad_booting

(На всякий случай) Установка на одной машине 4х ОС (XP, Vista, OSX86, Linux).

http://en.wikipedia.org/wiki/Psystar и http://en.wikipedia.org/wiki/PearC

Две компании, с которыми судились Apple (видимо, вы слышали про одну из них). Компании крупные и занимались они продажами железа с предустановленной Max OS X, что напрямую ударяло по бюджету яблочных. Если вы будете писать программы не на Apple PC, но при этом продавать их официально через App Store и соблюдать все остальные правила, то никогда в жизни никто с вами судиться не полезет. Просто не выгодно.

На сим по технический причинам закругляюсь.

Missing-male

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

А какие именно продукты и среды разработки использовать, я думаю, в большей степени зависит от поставленных задач: всё-таки теперь это практически два разных рынка, и выбирать, например, между Flex Builder и iPhone SDK - это примерно то же самое, что выбирать более сильное животное между китом и слоном.

Missing-male
+5

От того, что лично вы не купите себе iPhone, Apple'у ни холодно, ни жарко. Я думаю, они знают, сколько в мире противников их политики. А ещё они знают количество своих сторонников и цифры продаж. Эта их "закрытость" работает и приносит свои плоды уже несколько десятилетий. Не только самой компании, но и её пользователям, ибо я ещё не видел ни одного обладателя айфона/айпода/макбука, который был бы недоволен своей покупкой, даже не смотря на высокую цену.

Missing-male

Можно, по карйней мере на винде закачивал легко. Правда, половина музыки у нас в СНГ, как водится, не тегированная, так что айпод её в кучу может сбросить, но это скорее издержки источников аудио, а не самого устройства.

Missing-male

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

боюсь неправильно понять. что вы подразумеваете под "базой"?

Missing-male

По поводу базы готов подписаться под каждым словом. Единственное, стоит отметить, что переход MIT со Скима на Питон ознаменовал новый виток в развитии ИТ: как выразился сам Сассман, раньше нужно было сначала много подумать, а потом немного написать, сейчас же оснавная работа программиста - чтение мануалов и API используемых библиотек. И вся алгоритмизация, математика и высокоуровневые техники идут лесом. Как сможет Java-программист на Епаме использовать функции высшего порядка, если его язык их просто не поддерживает?

(Ну ладно, для функций высшего порядка есть паттерн Стратегия, а в Java 1.7 даже MethodHandler'ы обещают, но вот замыканий, на которых половина примеров в SICP'е основана, в языке нет и пока не предвидется).

Missing-male
+1

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

Missing-male
-1

http://habrahabr.ru/blogs/crazydev/31541/

Для кого-то - да, полезно интересоваться и писать на языках, не относящихся к основной специализации, но большинству (по личным наблюдениям) никогда и не приходится использовать фичи этих языков и весь багаж "продвинутых" знаний. Либо потому что ситуаций, где их можно применить не встречается (когда вы последний раз видели пример использования B-дерева, ленивых вычислений или регрессионного анализа?), либо потому что средства не позволяют. Уже несколько раз был в такой же ситуации, как и автор статьи выше: смотрел на код на Java, видел его уродливость, но не мог ничего сделать, хотя видел сразу несколько элегантных решений на Lisp и Python. Спрашивается, почему тогда Java? А потому что индустрия требует, потому что тысяча обезъянок в корпорациях вроде Епама (не обижайтесь, что я привожу в пример Епам, просто на мой взгляд именно это компания отражает общее положение на рынке) не могут безопасно, не заваливая проекты писать на языках вроде Лиспа или Питона.

Так вот, какое это всё-таки имеет отношение к теме распределения и базового CS. С одной стороны, мы говорим, что нужно давать студентам основные положения computer science, с другой - не даём им места, где эти знания применить. Они кричат "Ура! У нас убрали пол года высшей математики и ввели C#!". И с точки зрения нашей индустрии они правы.

Missing-male
-1

Если я ничего не путаю, то во времена написания оригинальной статьи .Net ещё не поддерживал анонимных функций, и, следовательно, пример был вполне правильный. Anyway, не сложно найти задачи, которые если и решаются на C#, то получающийся код выглядет мягко говоря уродливо. (попробуйте хотя бы прогнать пару тройку задач из того же SICP'а).

Missing-male

Скорее problem solver: http://en.wikipedia.org/wiki/Algorithm_of_Inventive_Problems_Solving

Насколько я понимаю, семантический анализатор на основе статистики + логический процессор а-ля интерпретатора Пролога + набор предопределённых правил для него. Вообще было бы интересно взглянуть, как они всё это совмещают.

Missing-male

Ну, также буквоедства ради :) Я потому и сказал про время написания _оригинальной статьи_, а не перевода на Хабре. Полагаю, оригинальной статьёй была эта, датированная 2006-м годом:

http://lukeplant.me.uk/blog/posts/why-learning-haskell-python-makes-you-a-worse-programmer/

Missing-male
+1

> Почему в наших реалиях госплан должна волновать степень пригодности выпускников к работе в мэйнстриме белорусского негосударственного IT (аутсорсе)?

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

Missing-male

Видимо, я не совсем правильно выразился. Завалить проект на Лиспе или Питоне как раз таки гораздо проще, чем на Java. Почему, можно прочитать у Пола Грэма ( http://www.paulgraham.com/javacover.html ):

It's designed for large organizations. Large organizations have different aims from hackers. They want languages that are (believed to be) suitable for use by large teams of mediocre programmers-- languages with features that, like the speed limiters in U-Haul trucks, prevent fools from doing too much damage.

Я видел много уродливого кода на Java; на Лиспе или Питоне (или даже на С++) у тех же программистов код был бы ещё в десятки раз хуже.

Missing-male

Даже если отбросить налоги, развитие одной области промышленности всегда подтягивает за собой другие, как бы то ни было. Совсем недавно один епамщик (сегодня как будто день на Епаме сошёлся :)) рассказывал, что как только перевели большую часть ваших сотрудников в новое здание, захолустное кафе, стоящее рядом, резко поднялось, расширило свой ассортимент и повесило на стенку широкоформатный телевизор. Точно так же и на государственном уровне: увеличивается количество специалистов -> поднимается вся область -> область требует сырья (в случае IT - интернета, компьютеров, еды для программистов) -> развивается экономика и все смежные области.

Missing-male
+1

А можно пример запроса пользователя и "сырья", из которого извлекатся ответ?

Missing-male

> одновременно с этим гос сектор теряет львиную долю самых одаренных кадров (вернее, они туда просто не приходят)

Как-то я не уловил мысль. Я говорю о том, что улучшение госпрограммы пошло бы на пользу всем, в том числе и самому государству. Где при этом государство теряет самых одарённых кадров? Или вы думаете, что чем лучше готовить специалистов, тем меньше их придёт на госпредприятие?

> но о случаях прочтения такими людьми, скажем, курса лекций по ООП (СУБД, паттернам проектирования - что пожелаете) я не слышал.

Вам не повезло, как раз курсы ООП и СУБД (и ещё ряд дисциплин) у меня в своё время вели замечательные практикующие преподаватели. Один из них, например, подыскивал в университете грамотных студентов в свою компанию. Другой, судя по всему, оставался ради получения научной степени. Вполне себе успешные люди.

Missing-male

То есть работа ведётся с онтологиями? Просто смущает фраза: "Мы не стали идти по пути “Semantic Web”, потому что в своей классической формулировке это не что иное, как попытка заставить людей писать на неких стандартных шаблонах, понятных компьютеру. " Насколько я понимаю из ваших слов, работа ведётся с теми же шаблонами, но извлечёнными автоматически по лингвистическим правилам (напр., подлежащее - сказуемое - дополнение). Тогда понятно, как извлекается структура, но непонятно, как ведётся собственно поиск, а именно, как вычисляется мера близости понятий (как определяется, что слова "автомобиль" и "машина" ближе по смыслу, чем "автомобиль" и "собака"?). Или она вообще не вычисляется, а вся фишка именно в отношениях отдельных термов/понятий (Джон являетсясыном Анны, Анна имеетбрата Фреда)?

Конечно, если это не коммерческая тайна :)

Missing-male

Что-то я совсем запутался в причинно следственных связях в ваших ответах. Я и не утверждал, что изменение одной госпрограммы сделает чудо и всем вдруг станет хорошо. Вы спросили "Почему [..] госплан должна волновать степень пригодности выпускников к работе в мэйнстриме белорусского негосударственного IT". Я ответил, что это должно волновать госплан, потому что от степени пригодности выпускников, работающих в том числе и на _негосударственных_ предприятиях, зависит _государственное_ благополучие. На что вы сказали: "одновременно с этим [с развитием коммерческого сектора белорусского IT? с увеличением количества специалистов?] гос сектор теряет львиную долю самых одаренных кадров". Каких кадров? Хороших айтишников? Почему он должен терять их, если общее их количество наоборот увеличится?

Missing-male

> да не идут IT выпускиники в гос конторы...

Ой, как вы ошибаетесь. Практически все бесплатники идут либо в госконторы, либо в ПВТ, ибо закон. Все перечисленные в этом посте компании, если я не ошибаюсь, - резиденты ПВТ, а наше государство этот парк холит и лелеет, естественно, не просто так. И я лично знаю нескольких человек, очень толковых, работавших ещё в студенчестве в серьёзных белорусских конторах, которые пошли по распределению как раз в НИИ или что-то вроде.

Missing-male

Вам спасибо за ответы, и дабы не заваливать Вас новыми вопросами, могу я попросить ссылки/имена/названия публикаций по этой теме?

Missing-male
+1

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

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

Missing-male

Ещё раз спасибо.

Missing-male
+2

Индексируется. Плохо, конечно, но индексируется:

http://googlewebmastercentral.blogspot.com/2008/06/improved-flash-indexing.html

Правда, ни одной ссылки по теме старше 2008 года я не встречал, так что за это время могло что-то измениться.

Missing-male

Дадада, очень здравое обсуждение, кстати, развеивает некоторые мифы и прочищает мозг.

Missing-male

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

Missing-male

Вы конвертировали те несколько отрывочных сниппетов кода, которые есть в статье, в UML? Мм, интересно посмотреть, что получилось :)

Missing-male

Больше примеров - постараюсь, выделять столько объёма для одного паттерна, честно говоря, не вижу смысла - зачем переписывать то, что уже написано :) Если вас заинтересовала тема, рекомендую обратиться к тем же GoF и подобным книгам (список можете найти на Википедии). Цель же данной статьи - дать общее представление о паттернах как о стандартных решениях стандартных проблем, а также заинтересовать людей в дальнейшем их изучении и (что даже более важно) выделении паттернов в своих собственных программах.

Missing-male
+1

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

Missing-male

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

Missing-male

Да, пардон, затупил :)

Missing-male

На основании опыта общения с людьми, которые там учились, например, или на основании читаемых там курсов, таких как курс 6.001.

Missing-male

http://icfpcontest.org/

Вот вам пример не олимпиады, но почти. Обратите внимание на список вузов, которые его проводили за последние 12 лет - белорусских учебных заведений там явно не ожидается. Также можете посмотреть на задание и сравнить его с тем, что обычно даётся на СНГ'шных олимпиадах.

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

Можно, кстати, устроить пару-тройку тестов в рамках даже dev.by.

Missing-male

Угу. Что такое нормальный и аппликативный порядок вычисления знаете? Как внутри closures выглядят знаете? Систему арифметических операций для целых и действительных чисел, а также рациональных дробей и полиномов, или там систему ограничений для вычисления одного (любого) члена уравнения по всем остальным написать сможете? А все эти вещи описаны всего лишь в одном из вышеприведённых курсов всего лишь в нескольких первых главах.

Наше образование страдает двумя основными сидромами:

1) однотипность изучаемого: в вузе могут несколько семестров подряд читать лекции по реляционным СУБД, но при этом ни разу не затронуть ни объектно-ориентированные, ни документо-ориентированные, ни какие-то ещё нестандартные базы данных;

2) затачивание под низкопробный продакшн для Epam, ITransition и т.д.: вместо того, чтобы давать на хорошем уровне алгоритмы, структуры данных и математику, большую часть времени уделяют изучению конкретных языков (многие из которых впоследствии никогда не используются).

Почитайте 6.001 (который SICP). Если на первых 20 страницах не найдёте для себя ничего нового и полезного, я готов признать равеноство наших и западных вузов.

Missing-male
-2

> И что это? Левая ссылка какая-то. Вместо того, чтобы кидать ссылки неизвестно на что, ты возьми прогугли "чемпионат мира по программированию".

Это не левая ссылка, это ссылка на один из чемипонатов, в котором учавствуют (и устраивают!) мироваые вузы, но в которых белорусских учебных заведений ещё долго не будет. Понятно, что в самых популярных и всемирноизвестных соревнованиях наши тоже будут принимать учавстие, вопрос в другом, почему они не принимают участие в других чемпионатах? А ответ очень прост - ресурсов не хватает. Сколько процентов из наших студентов ходят на олимпиады? Да, в общем то, и какой смысл им туда ходить? Главное сдать лабы "кое-как", пойти на 3-ем курсе на работу и дальше зарабатывать деньги, совершенствуя только те знания, которые непосредственно нужны в работе - как настроить драйвер для базы данных, какой тег использовать на страничке, как сделать буковки на кнопочке не чёрными, а красными. Так принято и даже иногда поощрается преподавателям. И никаких контестов.

> Кто тебе это сказал? Что за клевета? Я считаю себя, тех с кем я работаю и многих с кем знаком в IT сфере профессионалами, добросовестно и качественно выполняющими свою работу.

Я рад, что вы работаете в профессиональном коллективе. Но там сверху вы обмолвились, что с SICP'ом знакомы. Полагаю, что труды Кнута, Дейкстры и прочих великих тоже читали, так? А теперь скажите, сколько из этой литературы или описанных в них приёмов программирования преподаётся в университете? Если что-то и затрагивается, то материал даётся с лицом "я понимаю, что вам это никогда не понадобится, но меня сюда поставили, значит я должен прочитать лекцию". Может кому-то повезло больше, но мой личный опыт именно таков.

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

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

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

Missing-male
-1

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

Missing-male

Я обращался к другому человеку. SICP читают (вернее уже читаЛИ, увы) в MIT в качестве вводного в программирование курса, то есть для них это база, минимальный уровень. Логично, что вы этот уровень уже прошли. Но к сожалению, для большинства наших программистов (говорю исходя из личного опыта общения, конечно же) слова "асимптотическая сложность", "ленивые коллекции" или "символьные вычисления" ни о чём не говорят.

Missing-male
+1

По поводу курсов согласен, было бы неплохо заиметь их у нас, только откуда бы средства взять. По поводу фундаментальных знаний... ну как сказать. Есть языки, платформы, да и вообще понятия, которые кардинально различаются, а есть те, которые довольно близки между собой. Это я вам как почти специалист по семантической близости говорю :) Так вот, у нас принято делать упор на что-то одно и мусолить мусолить мусолить это. Например, курсы в нескольких семестрах подряд могут сводиться буквально к:

Pascal

C

C++

C#

На функциоанальное и логическое программирование - вместе один семестр. На теорию алгоритмов - один семестр, причём в основном всё сводится к 5-7 сортировкам. Искусственный интеллект - один семестр очень поверхностных знаний. Столько же времени уделяется на вообще посторонние предметы вроде охраны труда, русского/белорусского языка и пр. В итоге, большинство окончивших вуз считает, что всё реальное программировние сводится к Delphi/C /Java/C#, а всё остальное - это так, неудачные эксперименты (почти что цитата одного знакомого). Очень разносторонне, ага.

В развитых западных вузах это обычно выглядит как-то так (на примере курсов MIT, приведённых выше):

Введение в компьютерные науки и программирование.

Элементы конструирования ПО (ФП и ООП, паттерны проектирования, модульное программирование, уровни абстракции).

Введение в алгоритмизацию (основные стрктуры данных, связь между алгоритмом и программированием, расчёт сложности алгортма и т.д.).

Разработка компьютерных систем (модульность, сети, надёжность, безопасность).

Разницу чувствуете? У нас хорошо затачивают под основные направления (например, касательно языков - под императивные языки со статической типипзацией), на западе - под всю ширину известных на сегодня (в науке, а не только в промышленности) технологий.

P.S. Если вы хоть раз программировали на Haskell, то вряд ли когда-нибудь забудете разницу между нормальным и аппликативным порядком вычислений ;)

Missing-male
-1

Я хочу показать разницу между широтой преподаваемых у нас и у них предметов. У нас как-то односторонне всё - опять же, Delphi/C /Java/C#. И пусть даже вы только на этих языках и будете в дальнейшем писать, но если бы вы знали Scheme, то для вас не были бы новыми такие штуки, как лямбда-функции в .Net, если бы знали Haskell, то вас бы не пугал type inference. (Буквальная цитата, которую мне довелось слышать: "не, этот var в C# - это какая-то ересь, я её использовать не буду". А человеку просто не хватило широты мышления).

Missing-male
+1

То, что университет устрараивает подобные соревнования, предполагает, что он также готовит и мотивирует студентов для участия в них. У нас студентов мотивируют к общественной жизни, к изучению каких-то левых предметов и т.д. Если посидишь в приёмной комиссии, засчитают как несколько дней дежурства в общаге, а если разработаешь уникальную программу... ничего не засчитают. Помниться, на защите дипломного проекта у одного человечка 7 из 8 вопросов были по охране труда. По вашему, это нормально?

Missing-male
-1

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

Missing-male
+2

> Я готов согласиться с тем, что в MIT возможно есть один специфический курс по одной специфической дисциплине который раскрыт глубже и подробнее чем где-либо в наших ВУЗах.

Вот поэтому я и люблю приводить в пример SICP: там затрагиваются фундаментальные темы, показывается, как может быть реализовано большинство фич во всех языках, не только в Scheme. Курс затрагивает все основные темы, связанные с языками программирования, рантаймами, компиляторами и многим другим. Мне на получение такого же количества знаний понадобилось около 3х курсов и куча дополнительных источников. А многие люди, с которым я встречаюсь на работе, на форумах, в юзергруппах и т.д. и до сих пор не понимают таких базовых вещей. Чтобы сравнивать уровень выпускников, нужно быть HR-менеджером компании, куда стремятся попасть и те, и другие. Я же сравниваю только подходы к обучению, источники информации, которыми наши и зарубежные вузы пользуются, ну и немного опытом менеджеров крупных компаний, и тем, где они ищут кадры (например, Google периодически устраивает соревнования для студентов MIT с предложением победителям пойти к ним работать).

Missing-male

http://www.javamex.com/tutorials/synchronization_volatile.shtml

Declaring a volatile Java variable means:

* The value of this variable will never be cached thread-locally: all reads and writes will go straight to "main memory";

* Access to the variable acts as though it is enclosed in a synchronized block, synchronized on itself.

Другими словами, объявление переменной как volatile медернизирует все операции доступа к ней так, как если бы они были обёрнуты в блок synchronized. Если же у нас есть всего один метод, в котором может изменяться значение переменной singleton, то все операции над ней уже обёрнуты в блок синхронизации. Разумеется, в классе будут объявлены и другие методы, которые будут считывать значение переменной через this, но они уже будут работать с объектом инстанса, то есть тем объектом, на который указывает указатель singleton, а не на объект класса Singleton, в котором этот указатель объявлен. Соответственно, переменную Singleton.singleton изменить кроме как через синхронизированный getInstance() будет невозможно. (Если, конечно, в классе не будет объявлено других статических методов, работающих с этим указателем, что судя по всему и предполагалось на Википедии).

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

А вообще, спасибо, что проверяете, я думаю, ошибок в статье всё-таки хватает :)

Missing-male
+1

> Статья интересная, но бросились несколько нюансов. В предполагаемой цепочке рассуждений не хватает на мой взгляд одного пункта "какой паттерн нужно применить?"

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

Про "красивые" примеры учту, спасибо.

Missing-male

Поистине не предсказума блокирующая синхронизация! )

Спасибо!

Missing-male

Я думал об этом, но, если честно, 1) не нашёл подходящего примера; 2) не придумал красивого способа, как это впихнуть в текущий формат статьи (один раздел - один паттерн).

Немного проще сравнивать различные решения - через паттерн и через что-то ещё, как в примере с Singleton'ом.

Missing-male

> Действительно хорошая серия статей. Таких тут мало. Правда "мягкое введение" в названии сразу напоминает о недавно прошедшем http://www.sfpride.org/ :)

Ахаха )) На самом деле всё проще, название взято из статьи < a href="http://www.haskell.org/tutorial/index.html">A Gentle Introduction to Haskell, ну и соответствующего перевода - Мягкое введение в Haskell, без задней мысли :)

> double checked locking - это антипаттерн

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

1) раздел, включающий double-checked locking, посвящён в первую очередь паттерну Singleton, а двойная проверка является лишь побочным эффектом реализации;

2) в данном конкретном примере это работает, при переходе на другую платформу (CPP, .NET, и даже СУБД) правила написания кода могут кардинально различаться, описывать все-все-все возможные варианты для всех-всех-всех возможных языков просто бессмысленно;

3) если даже выводить какие-то общие правила для каких-то наиболее близкий языков (например, Java и C# сделать nested классы), то за всей этой мишурой потеряется сама идея Синглтона.

Missing-male

Это вопрос к администрации, к сожалению, движок сайта по умолчанию не поддерживает ни подсветки, ни даже фиксированных отступов. Сейчас ищу обходные пути, но пока не вижу.

Missing-male
+1

Вы, вероятно, ищете полную аналогию. Нет, разумеется фабрика и АТД различны по своей структуре и во многом по использованию - было бы странно, если бы языки из разных парадигм программирования имели абсолютно аналогичные конструкции / подходы. Под "отражением Абстрактной фабрики" подразумевается возможность некой структуры хранить ограниченный набор различных типов. Если хотите большей аналогичности:

data Car = Lamborgini | Ford | Ferrari

mkCar :: Int -> Car

mkCar 0 = Lamborghini

mkCar 1 = Ford

mkCar 2 = Ferrari

mkCar будет аналогична фабричному методу, а тип Car, естественно, интерфейсу Car в Java. Правда для автомобилей такой пример смотрится довольно странно и неудобно, поэтму в статье я и не стал его приводить.

Missing-male

> А то, что вы пишете на хаскеле достигается в си с помощью struct и union, что однако не делает их абстрактной фабрикой.

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

data Car = Lamborghini | Ford | Ferrari | LandRover Bool

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

Абстрактная фабрика является некоторой апроксимацией алгебраического типа данных - ADT более математически точен в своём определении. Фабричный метод возвращает объект с каким-то интерфейсом. Количество классов, которые могут этот интерфейс реализовать, может быть любым, в то же время, фабрика может возвращать не все из них. В ADT тип (в нашем случае Car) точно задаёт все возможные конструкторы этого типа. Всё-таки Haskell - язык доказательный и точный.

Вместо виртуальных методов в Haskell используется pattern matching, например, если в интерфейсе Car описан метод drive(), то в Haskell это будет выражаться в виде декларации типа функции:

drive :: Car -> IO ()

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

drive Ford = ....

drive Ferrari = ....

drive (LandRover b) = ....

Ещё раз, по пунктам:

1) объект определяется набором методов, которые над ним можно совершать: в ООП - это набор виртуальных методов, в Хаскеле - просто набор функций, которые принимают одним из параметров этот объект;

2) есть обобщённые объекты, поддерживающие альтернативу: в ООП - интерфейсы, которые могут реально ссылаться на экземпляры различных классов, в Хаскеле - алгебраические типы данных, которые могут иметь различные конструкторы;

3) для таких обобщённых объектов необходим механизм выбора конкретного метода для конкретной альтернативы: в ООП используются таблицы виртуальных методов, закреплённых за конкретными классами, в Хаскеле - pattern matching по конкретным конструкторам.

Если вам нужно создать именно семейства связанных объектов, то с помощью того же паттерн матчинга это достигается элементарно:

data Car = Lamborghini | Ford | Ferrari | LandRover Bool

data Wheel = LamborghiniWheel | FordWheel | FerrariWheel | LandRoverWheel

wheelDiameter :: Car -> Wheel -> Int

wheelDiameter Ford FordWheel = 5

wheelDiameter Ferrari FerrariWheel = (radius FerrariWheel) * 2

....

Естественно, фабрика обрастает особенностями, свойственными ОО-языкам, такими как возможность наследования (откуда и идёт название "Абстрактная"), ADT обрастает своими, такими как простой в реализайии double dispatching. Но с точки зрения моделирования ограниченого количества альтернатив и их поведения (а другие способы использования фабркии мне сложно придумать), они вполне взаимозаменяемы.

Missing-male

Промохнулся с ответом, смотрите ниже.

Missing-male
+1

> Может, кому-то этот синтаксис и покажется проще, чем Си или Java, но я вообще принципиальных отличий не заметил. IMHO, идея скрестить Си с Обероном довольно-таки тупиковая. Если авторам хотелось достичь прозрачности, то чистому Оберону они явно проигрывают.

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

Missing-male

> Тема на самом деле интересная, но вот в следующей статье лучше написать что такое Clojure и какое у неё практическое применение, для решения каких задач предназначена, примерчик небольшой.

Это можно. Смысл данной статьи был в первую очередь не в том, чтобы привлечь внимание как можно большего количества людей, а в том, чтобы помочь тем немногим, кто уже заинтересован данной тематикой, сэкономить кучу времени.

Мне вот только интересно, а не понадобится ли потом ещё описывать, что такое Emacs и какое у него применение :)

Missing-male

Промазал, см. ниже.

Missing-male

> тьфу, пропустил заголовок - кому пришло в голову делать его серым? :-)

Исправил заголовки на хоть и такие же серые, но более крупные :)

Missing-male

> Если я правильно понял, в Clojure реализовано то, что в Clipper называлось блоком кода и делало этот язык буквально "резиновым".

Судя по описанию Clipper - да, похоже. Только макросы ещё и вычисляются до компиляции основного кода. То есть у вас есть возможность сделать перед компиляцией всё то, что вы можете сделать и в самом коде. Абсолютно всё. Можно, например, при сборке проекта проверить коннект с бозой данных и выдать ворнинг, если его нет, или проверить версии библиотек или просто сгенерировать оптимальный код в зависимости от конфигурации системы, дабы не делать этого в рантайме. Кроме того, макросы позволяют создавать ленивые конструкции. Например, оператор and во всех языка программирования ленивый, то есть если первая конструкция равна false, то вторая вообще не вычисляется, что в языках с прямым порядком вычисления (не ленивых) с помощью функции оформить невозможно. Лисп же, используя макросы и код-как-список может свободно вычислять такие конструкции.

Да, ну и макросы, естественно, реализованы не только в Clojure, но и практически во всех Лиспах (кроме, разве что, AutoLisp'а, на котором AutoCAD написан), а также как минимум ещё в Nemerle (ещё один язык для CLR).

А вообще, если решили изучать ФП, обратите внимание ещё на Haskell - это, хотя и тоже функциональный язык, но совсем из другого семейста. В нём вы найдёте много других прелестей, таких как оооочень развитую типизацию, автоматический вывод типов по модели Хиндли-Милнера (http://en.wikipedia.org/wiki/Hindley–Milner_type_inference#algorithm), полная ленивость и много прочего.

Missing-male

Что-то мне не везёт с ответам куда надо, см. ниже.

Missing-male

Ну я вижу здесь как минимум один плюс - можно отследить, какие части кода сложнее всего даются для понимания (чтения). В данном случае ещё раз подтвердилось мнение, что сложнее всего программистам даются циклы. Напишите программу, например, с foreach, который гораздо проще, и диаграмма приобретёт совершенно другой облик.

Missing-male
+6

Красиво то как всё написано. А на практике:

1) протокол сложен для понимания и ручного описания;

2) автоматические средства генерации кода и WSDL-схем для разных языков не работают (лично проверял на парах Java-Python, Java-.Net);

3) UDDI не работает;

4) повышенные накладные расходы на обработку XML;

5) необходимость переизобретать колесо и создавать вручную всё то, что уже заложено в HTTP (коды ошибок, например).

Так посмотришь, а небо над SOAP не такое уж и ясное.

Missing-male

> Помимо этого широко используемого формата, также существуют и другие технологии, например REST. Эта технология, в принципе, включает те же возможности, что и SOAP, за исключением дополнительных возможностей, которые представляются тем же протоколом http, как авторизация и шифрование посредством https.

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

Missing-male
+5

Недостатки HTTP - это уже немножко другой уровень обсуждения :) По большому счёту, весь интернет тоже уже давно пора отправить на свалку и заменить его чем нибудь более вменяемым (чтобы было понятно о чём я говорю - попробуйте придумать защиту от атаки путём подмены DNS серверов). Тем не менее, лучшей альтернативы пока не сущесещствует, так что приходится довольствоваться тем, что есть.

А Спиди - это, конечно, хорошо, но пока что всё-таки experimental.

Missing-male
-1

Тиль, ты ли это?

Missing-male

Дело в том, что общий тон статьи звучит как "о, какая классная штука! в ней столько можно сделать!", как будто других аналогичных вещей нет. Вот и получается, что вы то ли не знакомы с аналогами, то ли специально не упоминаете про них, ради рекламы данной технологии. В общем-то, ничего плохого, но в качестве рекоммендации: в многопользовательском блоге как этот лучше сразу пояснять место описываемой технологии в мире ПО.

А по теме: чем плохи реализации компиляторов JS -> JVM (например, http://www.mozilla.org/rhino/jsc.html) или интерпретаторы скриптовых языков для JVM (например, Jython)?

Missing-male
+3

eval в любом языке и на любой платформе будет медленным, чё уж тут. В общем-то, в местах, где нужен eval, большой производительности как правило и не ищут. Ну и, в конце концов, если вы хотите использовать и eval, и производительную платформу, есть JRuby, есть Jython и IronPython, есть в конце концов Clojure, о котором я недавно писал, - и во всех них есть как поддержка высокопроизводительных библиотек, так и полноценный интерпретатор.

Missing-male

Я так понимаю, вас смущает, что на PHP, Python, Ruby, etc. не пишут приложений уровня энтерпрайз, причём по вашему мнению сугубо из-за производительности этих языков? Так что ли? Ну тогда давайте разберёмся, что считать приложением уровня энтерпрайз, и посмотрим на мировые аналоги.

Пара сайтов на вскидку:

livejournal.com - как гласит Педивикия, написан на языке S2, который компилируется в Perl.

twitter.com - долгое время использовал Ruby. Потом, правда, сменили на Scala, но отнюдь не из-за медлительности Ruby, а из-за плохой расширяемости и бажности последнего.

сервисы Google - точно известно, что гугль до сих пор активно использует Python. Да, скорее всего в связке с С++, но кто вам запрещает сделать то же самое для своего продакшена.

Yahoo - они периодически нанимают известных PHP программистов, что также отражено в их вакансиях.

Недавно, кстати, видел вакансию PHP-программиста в Epam. Так что все перечисленные языки вполне себе используются в энтерпрайзе.

Missing-male

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

что касается вашего последнего определния энтерпрайза (остановитесь уже хоть на одном из них):

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

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

Missing-male
+5

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

Missing-male

Конкурентов боитесь? :) Не беспокойтесь, в Минске вы их не найдёте.

Частично это тема моей магистерской диссертации, частично - помощь в одном западном проекте.

Missing-male
+1

> Скажите, а какие практические ограничения накладывает применение SVD-декомпозиции при использовании Latent Semantic Indexing (LSI). Ведь размерность матрицы SVD будет довольно-таки ограниченной на практике. Как это повлияет на конечный результат и точность?

Основная проблема с SVD - это его неинкрементальность. То есть матрицу коэффициентов приходится перестраивать при каждом изменении корпуса текстов. Изначально это делалось в рамках проекта по созданию электронной библиотеки. Нижняя граница объёма данных - 10Гб документов в форматах PDF и DOC, то есть около 1-2Гб чистого текста, 10-50 тысяч документов, которые нужно проиндексировать и получить из них матрицу. Сложность самого SVD преобразования - O(n^3). А теперь представьте, что эта процедура должна повторяться каждый раз при добавлении нового документа.

В такой ситуации инкрементальные методы, дающие практически константную сложность, выглядят куда более привлекательными. Хотя для небольших объёмов данных (на вскидку до 1000 документов), производительность вполне приемлимая.

Считается, что SVD - это наиболее точный и математически доказанный способ уменьшения размера матрицы, и, следовательно, должен давать наиболее точные результаты. Эти результаты колеблются для различных задач от 64 до 99% правильных ответов. Например, вышеуказанный фильтр спама при обучении на 30% целевых писем давал 97-99% (по крайней мере, его автор так утверждал :)).

Тем не менее, если сравнивать точность LSA + SVD, например, с RI, то разница небольшая. Sahlgren во Введении в RI утверждает, что результаты сравнимы с LSA, а иногда даже превосходят. Другие авторы как правило оценивают точность RI на несколько процентов ниже, чем LSA.

Полагаю вам также будет интересно взглянуть на PLSA (Probabilistic LSA) - скрещение LSA и теории вероятностей. Сам его глубоко не копал, но насколько я понимаю, этот метод вводит дополнительные улучшения за счёт анализа контекста конкретного терма.

> Можете ли посоветовать что-то LSA-ориентированное (плагин или библиотеку) для применения совместно с Apache Solr?

В зависимости от того, для чего вам нужен LSA. Есть lsa4solr ( http://github.com/algoriffic/lsa4solr/ ), но он только для кластеризации и написан на Clojure (хотя сделать обёртку обратно для Java, я думаю, будет не сложно). Других, более общих библиотек пока не видел. Да и, в общем-то, сомневаюсь, что они будут - при нормальном знании Lucene API матрица совместной встречаемости с любым коэффициентами (хоть с частотой, хоть с TF * IDF) строится элементарно. Если решитесь это делать , стучитесь, поделюсь парой строк полезного кода.

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

Какие именно лексические библиотеки вас интересуют? Анализаторы (tokenizer + stemmer), NLP?

Missing-male

> Получается, что общая сложность при индексировании корпуса документов с SVD-декомпозицией будет O(n^3*N^2)? Да уж...

Хм, а почему O(n^3 * N^2)? Вообще, если быть точным, то сложность SVD равна O(min(n^2 * m, n * m^2)), где n и m - размеры матрицы, т.е. общее количество документов и общее количество терминов. Если делать SVD-разложения после каждого добавленного документа, то получится сложность O(min(n^2 * m, n * m^2) * N) ~ O(n^3 * N), где N - количество документов, то есть всего примерно O(n^4). Если разделить процедуру составления матрицы и собственно SVD (для больших корпусов текста сначала проиндексировать всё, а потом провести разложение), то сложность будет, опять же, O(n^3).

Или я ещё какую-то операцию забыл?

Кстати, как раз вчера наткнулся на пост, в котором автор пытался разложить корпус из 14 тысяч документов и примерно 5 тысяч слов. По его утверждению на простом лэптопе это заняло несколько минут.

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

Да, есть ряд работ, в которых авторы ссылаются на WordNet. С точки зрения VSM два слова можно объявить синонимами просто положив их одни и те же документы - тогда их вектора будут идентичны (или, если примешивать другие случайные документы, просто очень похожи) и слова будут трактоваться как синонимы. Поэтому всё верно: термин-предметная область.

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

Missing-male

> нет, почему же: в Минске есть ряд компаний по этому профилю.

Компаний, занимающихся семантическими технологиями? 0_о Самое близкое, что приходит в голову, - это статистический анализ рынка (естественно, заподного), но это больше к статистике, чем непосредственно к семантике. Ну и плюс я знаю несколько разработок на основе онтологий/логического программирования. В Минске есть что-то более серьёзное?

Missing-male

> а комбинации терминов с учетом контекста.

Например?

Missing-male

Ну почему же. Если "Бог умер" и "Ницше" будут встречаться рядом, или даже если "Бог умер" и "Заратустра", а также "Заратустра" и "Ницше" (то есть через какое-то промежуточное слово), то можно и по одному слову.

Сложнее дело обстоит с многословными терминами, где одно и то же слово встречается в абсолютно не связанных терминах. Например, "Integrated circuit" слабо связан с "Integrated Development Environment". Здесь уже начинает работать NLP, и справляется с этим вполне неплохо. Пример можно посмотреть здесь: http://www.alchemyapi.com/

Missing-male

> Вот почему я с большой надеждой и восхищением смотрю на развитие отрасли и полагаю, что она все-таки станет неотъемлемой частью стратегии развития нашего государства, которое должно поднять ее «на щит».

Я чуть печенькой не подавился!

И мы говорим иногда «вернуться со щитом», то есть одержать победу; «вернуться на щите» - найти гибель в борьбе.

> всячески пропагандировать информационные технологии в учреждениях образования и СМИ;

Мне интересно, как это согласуется с указом №60 и всеми нововведениями по ужесточению контроля в интернете. Даже не так, как это согласуется со всеми мерами по усложнению деятельности в интернете?

Missing-male

Я в курсе. А теперь введите обе фразы ("поднять на щит" и "со щитом или на щите") в гугль и посмотите на количество результатов. Разумеется, я понял о чём идёт речь, но у меня и, как мне кажется, у многих других пользователей первая ассоциация была именно со второй фразой. Ситуация забавна именно тем, что в реалиях РБ для крестового похода ИТ возможны оба варианта - и то что его "поднимут на щит", и то, что оно "вернётся на щите".

Missing-male

Ещё один способ синхронизировать закладки в FF на dual-boot машине:

http://lifehacker.com/348858/use-a-single-data-store-when-dual-booting

Что касается групп закладок, то я использую другую схему: для посещаемых каждый день ресурсов есть Fast Dial, для того, что нужно обработать в ближайшее время - место на панели над вкладками, для информационных - отдельные группы в букмарках на боковой панели, а "инбокса" в принципе нету, ибо если откладывать разбор, то вообще никогда не упорядочишь их ;)

Missing-male

не, так прочитать - это TODO, то есть в верхнюю панель, чтобы на виду были)

Missing-male
+1

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

http://www.google.com/

http://www.yahoo.com/

http://www.yandex.ru/

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

Missing-male
+2

интересно, а почему это яндекс и яху для поиска сделали отдельные страницы? ;) я к тому, что гугль изначально придерживался идеи минимальной раздражающей рекламы, её же придерживается и сейчас. единственное, что более или менее часто попадается на глаза - это sponsored links, которых максимум 1-2 в результатах поиска, без крупных банеров, без цветных надписей и флеш-рекламы. чем плохо то?

я, кстати, так и не понял ваш принцип оценки степени эволюции IT компании. поясните?

> какие УНИКАЛЬНЫЕ идеи и продукты сотворил гугл?

MapReduce и BigTable, о которых они с удовольствием читают лекции в университетах мира, AppEngine, кроме которого нормальный бесплатный хостинг что для Java, что для Python фиг найдёшь, books.google.com, docs.google.com, translate.google.com и т.д. и т.п.

> типичный паразит

и на ком он паразитирует? :) на компаниях, которые скупает? если мой стартам купят за $100000 и сделают опен сорсом я буду совсем не против ;)

гугль активно скупает стартапы и ведёт исследовательские разработки, 90% из которых закончатся крахом, тем не менее 10% представят миру что-то новое и качественное. понятно, что они это не за спасибо делают, и что сами имеют с этого гораздо больше, чем мировое сообщество, но чем это плохо? сравните и скажите, что Epam сделал хорошего для мирового сообщества? что лично для вас?

Missing-male

интересно-интересно, и какие же идеи они убили?

Missing-male
-1

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

> реклама в Гмайл-почте, кстати, довольно навязчивая...

это есть :) но в то же время, зайдите на страницу mail.ru (про тут.бай с гуглевским движком, наверное, глупо вспоминать) - там рекламы всё-таки на порядок больше.

Missing-male
+1

Отличная статья. Единственное, что я бы не смешивал общее образование и "воспитание" с учителем, будь то боевые искусства, Сю Ха Ри или ещё что-то. Когда-то Брюс Ли болел идее создания массовых школ кунг-фу. Впоследствии он отказался от этой идеи, поняв важность индивидуального подхода. Здесь то же самое - учитель/преподаватель должен хорошо знать своего ученика, чтобы контролировать его рост, а в университетах десятки преподавателей общаются с сотнями студентов - о каком индивидуальном подходе может идти речь.

Примечательно, что в крупных софтверных компаниях подобный принцип уже давно применяетя. Если я ничего не путаю, в Epam у джуниоров есть шанс взять себе "куратора" и пройти путь до сеньёра за ~2 раза меньшее время, чем просто так.

Missing-male

Боюсь соврать, поэтому лучше уточнить у самих епамовцев, но насколько я это запомнил: джуниор, который хочет быстро подняться, сообщает об этом менеджеру. Менеджер смотрит, кто из сеньёров высказывал желание взять себе ученика. Что движет сеньёрами - дополнительный заработок, желаение поднять свои скилы по общению с людьми или почувствовать себя джедаем, воспитывающим падавана - мне неизвестно, но наверняка потраченное время либо учитывается в тайм-репорте, либо оплачивается сверху. Если на этот момент есть такие свободные сеньёры, они с джуниором договариваются и начинается активное обучение. Сам сеньёр практически не проводит "уроков", а только выбирает набор подходящих треннингов - благо таковых хватает, ну и, естественно, контролирует качество кода и пОнятость материала. В итоге претендент работает гораздо активней, чем обычные работники, но за это получает гораздо более быстрый карьерный рост.

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

Наше массовое образование - это тема для отдельного, очень большого разговора. Напишите пост ;)

Missing-male

Если парное программирование в данном случае - это совместное владение кодом и написание программ "в четыре руки", то нет, это не оно.

Missing-male

> Заўсёды практыкаваць "чатыры рукі" - задорага.

А вот, кстати, не факт. Брукс вон вообще советует работать в 20 рук (9 человек "обслуживают" одного главного). И пример Брукса, и парное программирование - пример уменьшения времени на коммуникацию между людьми. Но это уже тема для отельного разговора :)

Missing-male

скажите, а вы боевыми искусствами то занимались?

Missing-male

Это меня так колбасит, или это сообщение действительно то появляется в блоге, то исчезает? 0_о

Missing-male

> Как нибудь могу поделится подробностями, так как принимал непосредственное участие в этом начинании.

Был бы рад услышать.

Missing-male
+1

Я думаю, такие языки и не выходят из поля внимания.

Missing-male
-1

> 4) когда человек распределялся в компанию, думаю он был доволен, потому что его не отпарили в "уютные" уголки Родины, поэтому как минимум невежливо уходить после 0.5 года отработки

Очень часто не "человек распределялся", а "человека распределили", причём не редко против его воли. Так что довольным ему быть не обязательно.

А в "уютные уголки", если, конечно, речь идёт об отдалённых населённых пунктах, распределять не имеют права: должны распределить либо куда хочет, либо где прописан, но точно не третее.

Missing-male

Ок, если сильно насолить или комиссия окажется ну совсем уж неадекватной, а студент достаточно непрошарен, то могут. Но, во-первых, комиссия как правило достаточно адекватна, поэтому в места отдалённые практически никогда не посылает. Обычно распределяют в родную область, а то и район, либо оставляют в Минске, если есть заявки. Во-вторых, есть ряд хитройстей/уловок/аспектов. Например, если муж/жена уже распределены, то по желанию студента отправляют в тот же населённый пункт. Если в этом населённом пункте заявок на места по специальности нет, то дают свободное распределение. Ещё есть вопрос с проживанием - если предприятие забирает студента в неродной город, то обязано предоставить ему жильё. Соответственно, если предоставить не может - гуляй студент. Ну и ещё пара мелких пунктов точно была.

Где написано, не подскажу - всё из воспоминаний о своём распределении. Но то, что _любого_ человека куда-нибудь в Хойники засунуть права не имеют, а тем более не станут, это точно.

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

Missing-male

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

Missing-male
+2

Уже который раз вижу русский перевод вершин/сторон проектного треугольника, но правильного ни разу так и не увидел :) В оригинале вершины называются Good, Fast и Cheap. То есть Качество и Скорость переведены верно, а вот вместо Дешевизны вы почему-то поставили цену, то есть прямо противоположное понятие (при измерении). В итоге, следуя логике такого треугольника, получается например, что быстрая и качественная разработка будет стоить очень дёшево ;)

Missing-male
+7

Статья про продвижение своего _решения проблемы_. Убеждение Славы Панкратова в том, что его методика унылое ... решает какую-то проблему?

Missing-male

Пример из НЛП-шной книжки. Мать пытается заставить ребёнка пойти в ванную, ребёнок, как обычно, не хочет. Мать спрашивает чадо:

- Ты будешь купаться со своим утёнком или без него?

Чадо переключается на вопрос об утёнке и даже не задумывается, идти ли в ванную - этот вопрос уже решён.

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

Missing-male

Ну как бе я в своём комментарии и не затрагивал сам по себе метод, а только указал на аналогию в историях (способ помыть ребёнка == способ продвинуть свою идею) и на лично мне непонятные ответы вида "очень плохой совет: вместо попытки решить с ребёнком, что на самом деле лучше, рассказывают, как навязать ему своё мнение" или "ребёнку нужно всё логически объяснить, а если не поймёт, то он не профессиональный ребёнок", etc. Если я всё правильно понял, то статья рассказывает о том, как продвинуть своё решение в условиях, когда оно может быть встречено в штыки. Вопрос же о том, надо ли вообще продвигать свои решения и необходимы ли при этом "хитрости" общения, как мне показалось, выходят за рамки обсуждаемой в статье темы.

Или я тоже не понял, в чём соль?

Missing-male

Да, спасибо, исправил.

Missing-male

Обращайтесь :)

Missing-male
+3

Сравнение Sphinx vs. Lucene не совсем корректно, правильнее будет сравнивать Sphinx vs. Solr, и вот в таком ракурсе продукты вполне сравнимы и оба имеют как преимущества, так и недостатки. Например, у Sphinx'а лучше поддержка работы с СУБД, особенно SQL-ными. Зато Solr прекрасно умеет обрабатывать rich documents, такие как PDF и MS Word. Sphinx поддеживает больше типов данных, а Solr за счёт простого REST-интерфейса более открыт для использования из новых языков программирования. Для Sphinx можно получить поддержку создателей, для Solr/Lucene - поддержку комьюнити. Sphinx концептуально един и поэтому, вероятно, более прост для освоения, Solr использует ресурсы сразу многих проектов ASF, поэтому новые фичи добавляются значительно быстрее. В общем, сравнивать есть что, а выбор конкретного продукта зависит от многих параметров.

Если всё-таки сразу хочется "самое навороченное", то берите Nutch - вот в нём уже наворотов выше крыши.

Missing-male

> Суффиксное дерево вроде используется для быстрого нахождения подстроки в заданной строке.

Именно так.

> Интересно, в Lucene есть tokenizer, который бы сначала разбивал текст на токены, разделенные пробелами и знаками препинания, а затем для каждого токена возвращал бы все возможные суффиксы?

О конкретных реализациях я не слышал, но сделать было бы несложно. Только это был бы не токенайзер, а анализатор вообще: токенайзер делил бы текст на токены (то есть "foo", "bar" и "baz"), а затем бы уже применялись специальные TokenFilters. Примерную реализацию фильтра можно посмотреть в Lucene in Action в главе про синонимы - аналогично фильтру синонимов, этот фильтр должен был бы вычислять все суффиксы, запихивать их в стек и выдавать дальше по одному, при этом выставляя новым порождённым токенам-суффиксам атрибуты позиции такими же, как для оригинального токена. В общем, если знать механизм TokenStream'ов в Lucene, то всё тривиально :)

Правда для поиска по паттернам, начинающимся с wildcards, действительно пришлось бы переписывать часть ядра Lucene, и скорее всего именно обратный индекс - сейчас такие паттерны попросту запрещены (см. query parser syntax).

Missing-male

Приятно видеть, что SO не стоит на месте :) Правда, как заметил кто-то в комментариях, им бы не помешало сделать упор на теги, хотя бы boost factor полю с тегами добавить.

Missing-male

Сегодня попробовал такой вариант - действительно результаты лучше ) Хотел бы я взглянуть на формулу релевантости гугля.

Missing-male

Сам Doug Cutting, создатель Nutch, определяет свой продукт как open-source web-search engine, естественно, работающий так или иначе через Lucene - предыдущий проект Doug'а. Hadoop стал результатом попытки перевести Nutch на нормальные распределённые вычисления. Как свидетельствуют логи проекта, с июня 2005 года Nutch был подпроектом Lucene'а и получил статус TLP только в апреле 2010. Как бы Nutch не обрабатывал найденные документы, он всё же является приложением, как Solr, а не библиотекой, как Lucene, именно с этой точки зрения и было сделано сравнение. Проблема с этой веткой проектов в том, что в ней слишком много одноплановых проектов с пересекающейся функциональностью: Lucene, Solr, Nutch, Tika, Solandra, Compass - это далеко не полный список взаимодействующих проектов, и каждый из них либо использует часть другого проекта, либо переизобретает велосипед. Соответственно, довольно трудно говорить о каком-то разделении обязанностей между проектами - просто берите тот продукт, в котором больше всего нужных вам фич.

Missing-male

Ну, это знаете, как сравнивать MySQL и HDFS - вроде как оба для хранения информации, вроде оба поддерживают CRUD, персистентность и всё такое, но за рамками этого - у них ничего общего :)

Missing-male

Да, согласен, разделение идёт, но по крайней мере пару месяцев назад, когда я последний раз копался во всей этой связке, это разделение мне не показалось чётким. В любом случае, проекты живые, развивающиеся - это главное. А что выбрать и как соединить - вопросы уже второстепенные и легко решаемые :)

Missing-male
+4

"Большинство ведущих софтверных компаний" делают часть софта здесь не потому что здесь "команды лучше", а потому что здесь дешевле. Навскидку: Епам говорит, что сотрудничает с Oracle. По неофициальным данным зарплата software engineer в Oracle не опускается ниже $60k в год. Много наших "инжинеров" получает столько же? Ну и аргумент "наши программисты лучше, чем программисты Oracle-а" тоже звучит глупо.

Можно, конечно, крутить словаим, говоря, что Oracle, Mircosoft или IBM (все три - партнёры всё того же Епама) - это не те компании, которые подразумевались, но тогда покажите уж ту выборку зарубежных контор, которые делают часть своего софта здесь, потому что наши программисты круче.

Missing-male
-2

Ну, я, в общем-то, и не пытался сравнивать наших программистов и индусов :) Речь шла о сравнении наших аутсорсеров и собственных команд заказчика. Да, я полностью согласен, что цена - это далеко не единственный критерий выбора, но чаще всего это именно тот критерий, который вообще толкает IBM, MS, etc. отдавать заказы за границу - если бы не цена, то что мешало бы им отдать проект на разработку своим соотвечественникам или просто расширить штат?

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

Missing-male
-1

А почему "continuous" - это никак не "непрерывный"? Lingvo вон сразу сказала, что это именно такой и есть ;)

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

Missing-male

>> continuous - скорее "постоянно продолжающийся/возобновляемый", но не непрерывный :) А написано - так и на заборе написано ;)

Эээм, кроме лингвы и забора это ещё написано на гугльтранслейте, мультитране, ну и ещё так считает мой знакомый лингвист. Если упор делается на возобновляемость процесса, то принято говорить "resuming". Ну это так, дань занудству :)

Ну, на мой взгляд, вы тоже затронули темы чуть более высокого порядка, чем просто непрерывное интегрирование: инспекция кода, например, может проводиться независимо от интеграции модулей, а интегрирование с базами данных, как уже отметили ниже, это вообще отдельная песня. Вот и получается, что вроде как затронуты все стороны проверки работоспособности ПО, а соответствие спецификации/требования заказчика как будно и не нужно.

Тем не менее, спасибо что ещё раз напомнили про такую важную технику!

Missing-male
+6

А какое дело _западным компаниям_ до уровня расходов в другой стране? Речь идёт о сравнении _абсолютных затрат на производство продукта_, а не о степени удовлетворённости программистов, и при аутсорсинге эти затраты на порядок ниже. Иначе зачем тому же Oracle отсылать проекты за океан в даже не англоязычную страну, если можно нанять своих соотечественников, находящихся в пределах 50 миль от головного офиса?

Missing-male

Жаль, что статья написана всё-таки в виде основных ошибок, а не основных правил. Мне кажется, у нас не так много специалистов по large-scale computing, чтобы заинтересоваться основными ошибками, а вот людей, которые в принципе _интересуются_ такими системами, но _не имеют достаточного опыта_ в них, гораздо больше.

А в остальном, отличная статья, спасибо!

Missing-male

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

Я имею ввиду, что правила обычно составляются так, чтобы покрыть _все_ основные вопросы, а описание основных ошибок - так, чтобы заострить внимание на _некоторых_ особенностях. Получается так, как если бы вы объясняли первокурснику, что неправильно часто использовать случайный доступ (random access) к односвязному списку, при этом не объяснив ему, что вообще представляют из себя в памяти эти самые списки.

Missing-male
+5

Забавно, на том же хабре статьи по GTD пользуются популярностью, хотя ресурс вроде тоже не для манагеров, а здесь статья по тайм менеджменту получила столько минусов, что даже пропала из ленты. В итоге и так полуживая лента превращается в полного зомби, подкармливающегося только рекламой компаний, отчётами с конференций и редкими опросами самого dev.by. Лично у меня при таких тенденциях возникает вопрос: а стоит ли вообще стараться и писать статьи для этого ресурса, если сообщество не только не оценивает труд, но ещё и активно настаивает на том, что автор мудак?

В общем, +1 и всё-таки надеюсь, что продолжение будет.

Missing-male

Спасибо за статью - некоторых техник не знал.

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

Missing-male

Ну меня больше интересует "логирование" своих действий - не в блокноте же писать :)

Missing-male

Спасибо, сегодня попробую.

Missing-male
+6

> Как можно всерьез думать, что хаос может родить порядок?

Ну вообще-то о том, как из хаоса рождается порядок, целую науку придумали. Но это так, лирическое отступление.

Missing-male
+3

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

3. XML человекочитабелен. Как минимум в целях отладки гораздо удобней. Хотя, конечно, сам по себе XML слишком перегружен лишним текстом, тот же JSON в этом смысле гораздо быстрее сериализуется-десереализуется.

Missing-male
+2

Данные, как правило, тянутся именно в тот момент, когда они нужны и без них всё равно дальнейшей работы нет. Например, нужно отобразить список товаров на странице - вытянули из базы, отобразили в браузере. Пока не вытянешь, отображать нечего. RPC - это уже другая парадигма, практически: экторы, колбеки, очереди выполнения. Конечно, можно и SQL-запросы делать асинхронно, и RPC синхронно, но ИМХО, тут скорее не отношение общее-частное, а пересекающиеся множества - есть общее, но есть и значительные различия.

Скажем так, текст проще интерпретировать на любой стадии и для него нужно минимум специальных инструментов. Например, делаете вы простой REST-сервис, при работе с банарным протоколом вам сразу придётся писать и клиента, с текстовым же достаточно обычного браузера (по крайней мере для запросов GET и POST). Ну и к тому же, сложно даже представить, что какие нибудь Facebook или Twitter для своего API начнут использовать не простую в понимании XML/JSON схему, а сложный бинарный протокол с описанием вроде "имя пользователя начинается в пакете по смещению 50 байт, возраст - 120 байт, места учёбы - ...". Да и c HTTP сложнее было бы. Бинарные протоколы хороши, когда передаются сложные структуры данных, хорошо ужимающиеся при передаче: передал как есть, загрузил как есть - размер маленький, затраты на кодирование/декодирование отсутствуют. В остальных же случаях (пример с Fb API) тот же JSON вполне может посоперничать с ними.

А за статью спасибо, да. С особым интересом читал про уровни кеширования процессора (ещё с прошлой статьи), TLB, переключение контекстов и т.п.

Missing-male

> С помощью RPC данные тянутся в другой момент времени?

Если грамотно проектировать сервис, то да. Время обращения к БД более или менее фиксировано, а сервис может подвесить основное приложение и на минуту, и на 10 минут, и даже больше. Хотя конечно, как я уже говорил, можно и RPC делать синхронно, а SQL - асинхронно. Можно даже обычную функцию во фьючерс засунуть и потом результат забрать, но делается так ооочень редко (в процентном соотношении по сравнению с прямым вызовом процедур). То есть вопрос именно в сфере применения, контексте, если хотите, и он у RPC и SQL всё-таки довольно разный.

Впрочем, это уже философские вопросы, так что обсуждать можно бесконечно :)

Помнится, давным давно, когда я только начинал разбираться с XML, он вызвал у меня коллапс мозга именно по причине такого огромного количества лишнего текста. Особенно "доставляли" примеры типа:

< some-long-parameter-name>1< /some-long-parameter-name>

Missing-male
-1

Ну баги то всегда какие-то остаются, но этот какой-то уж слишком можорный, да. Тем более, что распространяется на семейство проектов Apache.

Missing-male

Почему? Почитайте обсуждение на Хабре, там подробно расписано, зачем сделано именно так. Детишкам разве что за использование switch по одной строке на пальцы наступать надо :)

Missing-male

Кстати, я так понимаю, что маразм с

"str_constant".equals(strVar)

вместо

strVar.equals("str_constant")

в последних версиях Джавы уже не актуален?

Missing-male
+3

Опечатка, спасибо.

Ну ок, смотрите. В Java нет ни замыканий, ни лямбда-функций, ни даже простых указателей на метод (в Java 7 укащатели появились, но по сравнению со Scala, Clojure или даже C# они, мягко говоря, многословны). Но зато есть паттерн Strategy, который их эмулирует. При этом современные JVM даже приучены распозновать и оптимизировать такие паттерны. Спрашивается, зачем программистам воротить огромные конструкции в виде анонимных классов с единственным методом, а виртуальным машинам тратить драгоценное время на попытку распознать эти паттерны, если можно напрямую в языке указать "сделай мне это, по возможности оптимизируй"? Ни скорость компиляции в байткод, ни уж тем более скорость JIT-компиляции от этого не только не пострадают, но ещё и выиграют. А уж программисты тем более.

Missing-male
-1

> я бы не сказал, что они огромные

сравните:

[Scala]

val lst = List(1, 2, 3, 4)

val lst2 = lst.map { n => n + 1}

[Java (with Collections from Guava project)]

List lst = generateListFrom1To4();

List lst2 = Collections.transform(lst, new Function() {

    @Override public Integer apply(final Integer n) {

        return n + 1;

    }

})

[Java (old plain)]

List lst = generateListFrom1To4();

List lst2 = new ArrayList();

for (int i : lst) {

    lst2.add(i + 1)

}

Во втором варианте используются Google Collections из проекта Guava (а если уж Google сделал себе такую библиотечку, то уж наверняка такой функционал используется довольно часто). Вместо одной простой анонимной функции в одну строчку и 15 символов используется аж 5 строк и дофига символов, при этом значимая строчка всё равно остаётся одна. В итоге это настолько неудобно, что в большинстве случаев проще использовать обычные циклы (которые тоже довольно многословны).

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

Во-первых, стратегии могут быть реализованы в виде анонимных классов, так что имени у них тоже нет. Во-вторых, вы смешиваете понятия класса, переменной и значений. ООП предполагает, что _классы_ должны отражать объекты внешнего мира (хотя то, как они "отражают" внешний мир, - это отдельный вопрос, но мы не об этом). В программе вы в первую очередь оперируете не классами, а переменными. И эти переменные ссылаются на значения - примитивы или инстансы классов. Переменные должны иметь осмысленные имена - в этом Фаулер прав. Переменные, но не значения. Объект java.lang.Object@1b0d2d0 не имеет имени - это просто кусок памяти. Вы манипулируете этим куском памяти из своей программы, даже если на него не ссылается напрямую ни одна переменная (например, если этот объект хранится в коллекции). Более того, вы можете создавать объекты в программе "по месту", не присваивая их адрес именованным переменным: myFunction(new MyObject()). Так чем же в таком случае функции отличаются от других объектов (неважно, именованных или неименованных)? Функция - это тоже объект, с той лишь особенность, что она является, что называется, callable. Можно, конечно, пожаловаться, что появление нового типа объектов нарушит стройную иерархию наследования от Object. Но спешу вас расстроить: эта иерархия изначально разрушена. Чем Callable-объекты хуже Throwable - объектов, которые можно "бросать"?

Девиз Вирта (изначально сформулированный Эйнштейном) - "make it as simple, as possible, _but not simpler_". Вирт много лет работал над языком, в котором бы был именно тот набор фич, который может обеспечить максимальное покрытие потребностей программиста, но при этом не создаёт противоречивых конструкций. Функции как объекты первого класса (first-class objects) уже давно стали такой фичей. В Java их нет, в результате чего студенты, изучающие Java, кроме самого языка изучают ещё и его "второй синтаксис" - паттерны. А этот "синтаксис" гораааздо сложнее.

Missing-male
-3

Не, ну с проверкой на Null то понятно. Хотя если в программе строка может быть равна Null, а мы при написании кода об этом забыли, то ещё вопрос, что лучше - поймать эксепшн тут или где-то дальше, в библиотеках, доступа к исходникам которой у нас нет. Но я немного про другое: я несколько раз видел упоминания о том, что при записи

"CONSTANT".equals(var)

для сравнения используется константа, которая уже есть в пуле строк. А при сравнении:

var.equals("CONSTANT")

во время вызова equals() "CONSTANT" создаётся заново, т.е. получается на один объект больше. Когда в первый раз это услышал, меня это жутко возмутило, но в памяти засело хорошо. А сейчас, с появлением очередной версии языка, стало интересно, сохранилась ли эта глупость с созданием лишнего объекта.

Missing-male
-2

Вопрос снимается: в байткоде эти конструкции отличаются только последовательностью загрузки на стек. По крайней мере так в Java 6 и Java 7.

Missing-male
-1

> Мы оперируем всем в совокупности, и классами, и переменными, и названиями методов. Чем больше названий, тем лучше. Тоже самое, что и комментариев. ava.lang.Object@1b0d2d0 - в программе я не оперирую такими объектами, это их реализация. давайте не будем смешивать исходный код с реализацией. [...] Удачно подобранное имя может сэкономить час отладки при суппорте.

Я, честно говоря, не понимаю о чём мы спорим. Начали с лямбда-функций, затронули функции как объекты первого класса вообще, а закончили именами. Мой тезис был: функции в программе ничем не отличаются от других объектов. Вы говорите: функция - это просто кусок памяти (кода), ну так и объекты в таком ракурсе - это тоже просто куски памяти. Вы говорите: плохо, что у них может не быть имени, ну так и другие объекты тоже могут фигурировать в программе не имея имени. Отличие то у них в чём? Чем лямбда-функции противорерят учениям Фаулера и ко.?

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

> Какая разница, сколько символов. Зачем стремиться к тому, чтобы написать всё в одну строчку? Тем более остальные строчки поясняют первую.

Не в одну строчку, а наиболее лакончино и понятно. Меньше кода ведёт к тому, что его:

1) быстрее писать. Пусть не сильно быстрее, но если вам нужно успеть сдать проект к сроку, этот параметр тоже надо принимать в расчёт;

2) его легче читать и воспринимать. "фрукт, с зелёной кожурой, кисловатый на вкус" воспринимается сложнее и дольше, чем "яблоко".

3) его проще отлаживать. ну тут дело больше не в количестве кода, а в количестве объектов, которыми вы оперируете. задачу Эйнштейна помните? ну ту, в которой нужно постоянно держать в голове информацию о 5 людях, у каждого из которых есть по 5 атрибутов? ну вот, в голове она решается с трудом, потому что чем больше объектов человеку приходится держать в голове одновременно, тем задача для него сложнее. соответственно, чем меньше объектов (и кода), тем человеку проще и он совершает меньше ошибок.

> Во-первых есть название супер класса, во-вторых есть название метода.

Эээ... Название суперкласса - Function, название метода - apply? Ну да, очень понятные названия, а главное, как хорошо они описывают предметную область ;)

> Патерн стратегия никто из явы не выбросит, поэтому распознавать его всё равно надо будет. Я не знаю про какое распознавание идёт речь, в случае анонимных классов javac генерит просто ещё один внешний класс с полями, в которых будет содержаться текущий контекст.

_JVM_ оптимизирует паттерны. Пытается найти такие анонимные классы и места их использования, и при возможности соптимизировать. Как соптимизировать? В голову сразу приходит вынесение метода apply (invoke, call, etc.) в метод класса, где эта Стратегия используется, чтобы не не пихать в PermGen лишний класc, а в рантайме не вызывать по чём зря конструктор объекта, который там вообще ни к чему. Если бы была инструкция для прямого создания такого анонимного метода, всей это мишуры можно было бы избежать.

> Вы когда нибудь писали компиляторы?

Да, писал. И давайте не будем меряться письками и переходить на личности.

> Во первых не на пару, а на пару сотен, я про javac.

Для введения лямбда-функций в нормально спроектированный компилятор нужно всего лишь добавить в синтаксический анализатор одну-две строки для распознания конструкции, возможно в AST пару-тройку примитивов для представления функций-не-методов и в кодогенератор/байткод добавит какую-нибудь инструкцию invokelamda. С замыканиями да, сложнее - там нужно ещё контекст тянуть. Ну так и пойти по пути C# и сделать просто синтаксический сахар для оборачивания анонимных классов никто не запрещает.

В общем, надуманные у вас какие-то проблемы. Так делали, делают и будут делать. Но только пока так делают в других языках, Java рискует остаться за бортом современных языков программирования.

Заметьте, я про функциональные языки ничего не говорил. Лямбда функции есть в Python, C#, а сейчас ещё и в C++ появятся. Возможность передавать функции как параметры была ещё в древних C и Pascal. Ну и далее по списку ещё 2 десятка императивных языков с лямбда-функциями, ага.

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

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

> Вы считаете, что паттерны это плохо? Интересно в чём? Лично мой опыт показывает, что во многих случаях лучше применить всем известный паттерн, чем что-то изобретать.

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

Missing-male
+1

ilya_d, вы в конце концов определитесь, о чём вы со мной спорите? Откуда вы уже взяли рекурсию и вызов нескольких функций в одну строчку? И начните, в конце концов, читать мои ответы, а не цепляться за отдельные слова. Причём тут C++ - пример для подражания? Речь шла о том, что лямбда-функции уже давно стали частью императивных языков, а указатели на функции/методы были там изначально. И в процедурных, и в ОО-языках функции высшего порядков есть. Функциональное программирование тут не причём. Всё. Никакого подражания.

> java - это не функциональный язык, и не надо применять к нему терминологию функционального программирования. также как и к Паскалю, в котором есть просто указатели на функции, а не "объекты первого класса".

Про функциональный/не функциональный уже ответил.

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

> Фаулер как и многие другие, предлагает использовать название метода, как комментарий того, что он делает.

#{ n => n + 1 } // чёрт побери, как же я догадаюсь, что делает этот метод! его обязательно нужно вынести в отдельный метод plusOne! а если мне нужны будут несколько похожих методов, например #{ n => n * (n + 1) }, #{ n => -n + 1 }, #{ n => 1 / n }, то каждый из них мне нужно будет вынести в отдельные именованные методы - numberMultipliedByNumberPlusOne(), minusNumberPlusOne(), oneDevidedByNumber().

Очень часто... нет, не так. ОЧЕНЬ часто в лямбда-функции выносится код, который не несёт отдельной смысловой нагрузки и смысл которого лучше всего выражается как раз самим этим кодом. Вопрос к вам: в чём преимущество вынесения такого кода в отдельные методы с идиотскими названиями?

> Можно написать алгоритм через рекурсию, я потом 2 часа вкуривать как он работает. Почитайте "Мир Лиспа", посмотрите, примеры программ, и вы поймёте, что в одну строчку, это ни разу не понятнее.

Если лично вы не умеете писать (и читать) рекурсивные функции, это не значит, что они менее понятны. Причём тут методы по 100 строк - я тоже не понял: декомпозиция на небольшие функции как раз очень сильно приветствуется в Лиспе, и "Мир Лиспа" тому пример. Но, как я уже говорил, к лямбда-функциям ни рекурсия, ни декомпозиция не имеют никакого отношения.

> Я считаю, что в java стоит добавлять только концептуальные вещи вроде дженериков и аннотаций, а не синтаксический сахар.

Нифига себе у вас синтаксический сахар. Синтаксический сахар - это когда можно в дженериках вместо new HashMap< String, String>() писать HashMap<>(). А лямбда-функции - это не менее принципиальное изменение, чем дженерики или аннотации. Или вы считаете, что дженерики и аннотации нельзя эмулировать? Всё, что делают дженерики, - это выводят проверку типа из рантайма в компиляцию, повышая производительность. Принципиальных возможностей это не добавляет. Аннотацации предоставляют мета-информацию, при этом в этой метаинформации не бывает ничего такого, что нельзя было бы закондировать в названии (как это делалось в старом JUnit) или подцепить через механизмы наследования (как это было в Spring < 3.0). Соответственно вопрос: почему в таком случае лямбды - это синтаксический сахар, а дженерики или аннотации - нет?

> C# всё равно не догоним, а язык испортим

То есть C# всё-таки лучше? Или в чём не догоним? :)

> неправда, есть ещё контекстные зависимости. одни и те же символы в разных контекстах имеют различный смысл

Во всех вариантах синтаксиса лямбд, которые я видел, выражение начинается с #, которая вроде больше никгде в Java не используется. Соответственно, никаких общих символов.

Ну это ещё ладно, предположим даже, что время компиляции в байткод увеличится на 100 миллисекунд. А конструкцию с анонимным классом вы будете писать минимум 10 секунд. В итоге потеря скорости всё равно в 100 раз больше. Тут то вы как предлагаете решить эту проблему? :)

Ну и напоследок ещё раз спрошу: вы против чего: против замыканий, против функций высшего порядка или против безымянных функций?

Missing-male

> против безымянных методов и указателей на методы. ибо это противоречит ООП.

> лямбда - во первых противоречит ООП, т. е. это метод, не привязанный ни к какому классу, и ещё без названия.

> В ООП объекты между собой обмениваются сообщениями, а не объект с методами. метод, это не объект и с ним нельзя обмениваться сообщениями.

Да я смотрю у вас своё ООП, с блекджеком и обобщённым программированием ;) По вашему мнению C#, Delphi, Python, Ruby и ещё два десятка ОО-языков с поддержкой замыканий - это на самом деле не ОО-языки? :)

Про имена функций.

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

[pseudo-Scala]

def readFiles(files: List[File]) = {

  files.map { file => file.read() }

}

Пример 2. Функция подсчёта общей длины списка строк, например, для оценки памяти, которая понадобится для их хранения:

def overallLength(strs: List[String]) = {

  strs.map { s => s.length } foldLeft(0) { (lenBefore, curLen) => lenBefore + curLen }

}

Итого 3 лямбда-функции. Придумайте им осмысленные названия, но только не такие, чтобы { s => s.length } называлась lengthOfStr(), а { file => file.read() } - readFile() ;)

Про рекурсию. Я так и не понял, причём здесь рекурсия, но так и быть отвечу. Если команда пишет на Lisp и при этом рекурсивыне алгоритмы понимает только один человек, то команда выбрала не тот язык программирования. Если же команда пишет на Java, то и нет смысла делать упор на рекурсивные алгоритмы. Так что дело тут не в рекурсии и итерации, а в соответствии людей и инструментов, которые они используют.

Про то, как дженерики и аннотации хорошо, а лямбда-функции плохо и противоречит ООП - бред. Отвечать лениво, всё равно не поймёте. Напоследок, почитайте про парадокс Блаба и почувствуйте себя Блаб-программистом.

Missing-male

Во-первых, почему вы считаете, что лямбда-функции не принадлежат ни одному классу? В Java они принадледат тому классу, внутри которого объявлены.

Во-вторых, не противоречат ли тогда ООП статические методы, которые проде как тоже не принадлежат никакому классу и могут вызываться даже без создания инстанса. Предполагаю ответ, что не противоречат. Тогда сразу следующий вопрос: а по каким вообще параметрам вы определяете, какие методы кашерные, а какие нет?

В-третьих, кроме привычного вам ООП с наследованием, инкапсуляцией и т.д. есть и другие его виды. Например, в JavaScript реализовано ООП на основе прототипирования, в Haskell ООП сводится, грубо говоря, к реализации интерфейсов, а в Smalltalk, который и дал развитие всему ООП, оно основано на сообщениях, которые, в отличие от вызова методов, действительно действуют как сообщения со всеми вытекающими. Соответственно вопрос: _ваше_ ООП как-нибудь соотносится с другими его видами, или все остальные виды ООП (в том числе реализованное в Smalltalk) - это ересь?

Ну и да, вы не привели имена для моих примеров анонимных функций.

Missing-male

Насчёт 1000 улучшений, в принципе, согласен. Но тут какое дело. Со временем требования к языкам программирования меняются. Сейчас, например, активно развиваются параллельные вычисления, и от языков требуется наличие инструментов, позволяющих просто и эффективно разрабатывать многопоточные программы. Если язык не меняется, не добавляет необходимые фичи, он становится неудобным и умирает. Ну, не то, чтобы совсем умирает - для некоторых задач он всё равно остаётся хорошим инструментов, но сути это не меняет.

Missing-male
+9

никогда не забуду слов одной знакомой: Детройт - один из самых грязных и бедных городов Америки, где люди работают на заводах по 12 часов в день, чтобы оплатить свою лачугу, а возвращаясь домой думающие, как бы их не пырнули ножом; тем не менее, это не помешало Детройту стать родиной техно, запустить музыкальный лейбл и порадить ряд известных исполнителей. вы наверняка работаете от силы 8 часов в день в уютном офисе с кондиционером и думаете, куда бы съездить летом. я понимаю, что у нас полно запретов, полно маразма, да и вообще кризис, но неужели в Минске ситуация хуже, чем в Детройте?

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

Missing-male
+1

Анекдот вспомнил. В селе начинается потом, все спасаются как могут, и только один мужик сидит и даже не собирается выбираться. Соседи ему издалеко кричат:

- Василий, вон бревно мимо плывёт, хватайся скорее! Спасёшься!

- Нее, не буду. Я всегда в Бога веровал, каждый день молился, в церковь еженедельно ходил, и сейчас уверен, что он меня спасёт!

Соседи удивились, но надо самим спасаться, ушли.

Воды уже по грудь. Мимо плывут спасатели на лодке. Кидают мужику верёвку и кричат:

- Мужик, хватайся скорее, мы тебя вытащим.

- Нее, меня Бог спасёт, плывите дальше.

Ну делать нечего, уплыли.

Вода уже затопила всю хату, мужик сидит на крыше. Пролетает спасательный вертолёт, соберает последних жителей. Из вертолёта кричат:

- Эээй, снизу, щас трос скинем, хватайся!

- Нее, меня Бог спасёт...

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

- Господи, я же всегда в тебя верил, всегда молился, в церковь еженедельно ходил... Господи, почему же ты меня не спас??

- Ну, Василий, смотри сам. Я тебе бревно посылал? Посылаааал. Я тебе лодку посылал? Тоже посылааал. Вертолёт спасательный, в конце концов, я тебе посылал? Посылааал. Ты ими воспользовался? Нет. Так какие тогда претензии ко мне?

Мораль: вера в славное будущее - это хорошо, но она не отменяет необходимости самому на это будущее поработать. И в этом я с вами полностью согласен. Но _хотя бы_ вера в то, что чего-то можно добится, быть должна.

Missing-male

Для этого нужны данные. Пример с публично доступными наборами данных обязательно приведу, а приватными данными никто, как правило, делиться не хочет. Можно, конечно, попробовать сделать что-то с opinion mining, но для этого нужны кое-какие знания по обработке текстов. Хотя, если есть желание, могу быстренько накидать утилитку по переводу текста в набор признаков.

Missing-male

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

Есть вариант проанализировать ассоциации между технологиями в вакансиях на dev.by. То есть просто забить все возможные технологии в базу, распарсить вакансии и посмотреть, какие связки технологий чаще всего используются на практике. Я делал похожую вещь с LinkedIn, только вместо вакансий использовал профили людей. Обноружил довольно неожиданные для себя зависимости (например, оказалост, что очень многие люди, знимающиеся маркетингом впоследствии переходят в менеджемент и наоборот).

То же самое можно сделать, например, с тегами на StackOverflow, ну и вообще с любыми данными из соц сетей.

Другой вариант - проанализировать статистику по покупкам/просмотрам/скачиваниям. Можно, например, собрать информацию о новостях, просмотренных с одного IP-адреса. "Обезличенные" такие данные не представляют собой коммерческой тайны, но являются прекрасным ресурсом для data mining. К сожалению, я не являюсь владельцем ни одного такого сайта, а те данные, с которыми работаю, увы, раскрывать не могу. Если кто-то может предложить такие данные, это могло бы стать замечательным примером.

Есть, конечно, популярные репозитории и даже целые сайты для поиска наборов данных, но вряд ли это можно назвать day-to-day usage.

Так что если есть какие-то пожелания или предложения, с удовольствие выслушаю.

Missing-male

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

Обилие картинок "по теме" будет в следующей части :)

Missing-male

Ради интереса зарегался на ml-class, но, честно говоря, не уверен, что будет время на полноценное изучение. Чувствую придётся скачивать и дочитывать материал в дальнейшем :)

Missing-male

Не данных, а информации, не полезных, а скрытых и интересных. Данные то все полезны, но если в базе системы учёта времени есть запись , то нет смысла применять алгоритмы извлечения данных, чтобы узнать, что Вася потратил целых 8 часов на исправление одного бага.

Missing-male

А какого разработчика считать крутым? Того, кто сделал больше всех коммитов, или исправил больше всего багов, или написал больше всего строк кода? :) Не помню где, но где-то была история о том, как в одной компании вели учёт количества строк написанного кода. Один программист очень не любил эту систему, но вынужден был следовать ей. После очередного рефакторинга в своём отчёте он написал "- 200 строк". После этого его больше не просили заполнять такие отчёты :)

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

Missing-male
+1

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

Но можно пойти другим путём: попросить коллег или тим лида оценить каждого разработчика, скажем, по десятибальной шкале, а затем уже использовать статистику по багам, таскам, etc. для построения модели оценки разработчика. И вот уже эту модель использовать для оценки других программистов. Но тогда нужна внушительный набор данных для обучения - для самой грубой оценки нужны как минимум человек 30. Если обеспечите мне такую базу, модель я вам построю :)

Missing-male
+1

Почему-то меня приследуюет ощущение, что меня активно троллят. Люди никогда не будут объективны, но усреднённые значения от нескольких людей как правило считаются более или менее объективными (не только в статистике, но и в социуме). А то, что предлагаете - это как раз ваша односторонняя оценка разработчиков. Вы сами жёстко определили параметры, сами задали "веса", которые следует прибавлять или отнимать от "кармы" программиста. На каком основании вы выбрали именно эти параметры? Просто взяли из головы. А ML как раз и стремится не брать показатели на угад, а методично отобрать нужны и придать им нужные "веса".

Missing-male

Тогда ещё раз про Васю и Петю. Если джуниор Петя пишет программы на уровне разбора файла конфигурации, а сеньёр Вася пишет новую систему сжатия данных, то Петя сможет за вечер настрочить 3 тысячи строк, в которых не будет ни одной ошибки из-за тривиальности кода, а Вася весь день потратит на две маленькие функции, при этом будет вносить в них массу измненений, чтобы протестировать результат. В итоге Петя по вашей системе получит + несколько тысяч, а Вася из-за своих правок получит значительный минус. И таких моментов может быть много. Два коммите, после которых появился баг - кто из комитчиков виноват? Баг видет внешне, но какая именно строка виновата не понятно, а значит и не понятно, кто виноват. Провели рефакторинг, удалили 1000 строк - непонятно, увеличивать или уменьшать карму. Выбрали неправильную архитектуру, написали в 10 раз больше кода, чем можно было бы написать - система показывает большой плюс, хотя на самом деле это жирный минус. И так далее и так далее.

Missing-male

> при этом никто не мешает в тикет системе вводить баги, которые не будут учитываться при подсчете кармы. Это уже административное решение, потому что баги разные бывают. Вполне возможно, учет бага, как бага влияющего на карму может быть и коллегиальным решением команды. Когда все согласны, что косяк имеет место быть.

Очень напряжно для команды. Команда должна думать о том, как лучше сделать продукт, а не о том, как назвать баг - просто багом или багом с прибамбасами. А если это ещё и на каааарму влияет...

Вообще введение системы с кармой требует другой методологии. Похожую вещь используют ребята из StackExchange - они расчитывают зарплплату разработчика в соостветствии с их "полезностью" для компании, при этом "полезность" расчитывается не только по коду, но и по участию в конференциях от имени компании, написании статей в блоги и т.д. Мне кажется, систему, которую вы предлагаете, можно ввести в отдельно взятой команде или небольшой компании, но при этом выводы делать тоже не по коду, а по общему впечатлению о программисте. Например, разработчик предложил хорошее архитектурное решение - +20 в карму, разработчик не проставился на свой др - -100 в карму, потому что все ему скинулись на подарок, а теперь ходят злые и работать не хотят :) Но, в любом случае, полезность работника нельзя расчитывать исходя только из его кода, тем более с такой узкой метрикой как строки + метки.

Missing-male

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

Missing-male

А зачем его переводить во что-нибудь другое? Fb компилирует PHP код в сишный, так что по скорости проблемы явно есть. MVC можно делать на любом языке, даже на PHP, который вроде для этого не задумывался. Новые сервисы можно написать на любом другом языке и подключить к уже сущуествующему через HTTP/sockets/DB etc.

Missing-male

Орфография ни к чёрту, но будем считать, что мысль я понял.

Во-первых, не на Java, а на Scala. И не переводят, а только переписывают back-end. В front-end нет причин отказываться от Ruby. Ребята достаточно технически грамотны, чтобы использовать любую технологию, которая даст выигрш, будь то Scala, Ruby, Python или PHP. Да и вообще Twitter - это образец прагматичности.

Во-вторых:

http://developers.facebook.com/blog/post/358/

"HipHop programmatically transforms your PHP source code into highly optimized C++ and then uses g++ to compile it. HipHop executes the source code in a semantically equivalent manner and sacrifices some rarely used features — such as eval() — in exchange for improved performance. HipHop includes a code transformer, a reimplementation of PHP's runtime system, and a rewrite of many common PHP Extensions to take advantage of these performance optimizations."

Missing-male

Вот я и говорю: запятые ставить надо.

300 метров в памяти? Для облаков с 32 и более гигами памяти это как бы не показатель. 300 метров на диске - тем более. Ну и есть у меня сомнения, что вы с Fb действительно одними и теми же инструментами пользуетесь.

Missing-male

Дзякуй.

Рэзюмэ Барні - гэта наступная ступень эвалюцыі :)

Missing-male

Точно! Добавил в пункт о headline, спасибо.

Missing-male

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

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

А вообще главное правило при описании навыков на любую должность - встать на место работодателя и подумать, что ему от вас может понадобиться.

Missing-male
+1

Згодны з усім, акрамя аднаго пункта - фатаграфіі. З аднаго боку так, з ёй лягчэй. З іншага - у некаторых краінах Еўропы даданне фатаграфіі да рэзюмэ заканадаўча забаронена, бо можа атрымаецца дыскрымінацыя па знешнім выглядзе :) Так што зноў жа - як пашанцуе з працадаўцам.

Missing-male

То есть, как я понимаю, вы не обращаете внимания на показатели уровня владения технологиями, а просто смотрите наличие/отсутствие их в резюме? А как тогда быть с описаниями типа того, что приведено в статье, на которую дал ссылку Ratmir, когда в резюме указано просто "C++, Python, Java", но нет ни слова о том, насколько хорошо человек знает каждую из технологий? И может оказаться, что он спец по Java, а вам скорее нужен питоновец со знанием C++?

Или я неправильно понял мысль?

Missing-male

Вот поэтому я предложил добавить в резюме как можно больше конкретных фактов, а не субъективных оценок типа "Expert" :) Согласитесь, если человек показывает кусок своего кода из опен сорс проекта, то это уже кое-как его характеризует. Если подробно рассказывает, как использовал некоторую технологию, то по крайней мере можно быть уверенным, что он с ней знаком (на интервью, конечно, стоит задать пару "контрольных" вопросов, но это именно для контроля, а не с целью выяснить уровень владения, который должен быть понятен из фактов, описанных в резюме).

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

Missing-male

Ну, на месте интерьвюера мне не так часто случалось быть, да и то в основном когда искал людей для своих проектов, но вот на месте кандидата побывал прилично. И обычно на интервьюера производили наибольшее впечатление именно психологические трюки. Как минимум, уверенность в себе. Это как со студентом на экзамене - если даже не ответил на какой-то вопрос, но ведёт себя уверенно и видно, что учил, то скорее всего просто забыл. А если сидит трясётся, значит скорее всего не учил и не знает, а на вопросы если и отвечает правильно, то просто потому что ему везёт.

И в таком ракурсе резюме позволяет сформировать первое впечатление, которое закрепляется в течение первых 3-5 минут разговора на интервью, т.е. того времени, когда технические вопросы ещё даже не начали задавать.

Но это тоже уже субъективный опыт кандидата.

Missing-male
+2

Ну вот видите, у вас уже сформировалось некое мнение обо мне, хотя технологий, которыми владею, я не перечислял и ни на один вопрос "для собеседований" я пока не ответил :)

Missing-male

Зигмунд Фрейд считал, что психоанализ должен стоить дорого. Если пациент платит мало, то подсознательно считает, что и эффект от лечения слабый либо вообще отсутствует. В докозательство этого Фрейд еженедельно встречался с одним пациентом совершенно бесплатно. С этим пациентом он отмечал очень медленный прогресс.

Мне как-то отказали в одном разовом проекте потому что я попросил мало денег. Взяли человека с очень похожим профилем, но со ставкой в ~1.5 раза выше моей. При этом мне не было задано ни одного вопроса, так что скилы действительно оказались не причём :)

Missing-male

"Дешёво значит плохо" - это общечеловеческий подход, не зависящий от психического здоровья. Если вы приходите в магазин и видите туфли за $10, а рядом другие, очень похожие, но за $100, и при этом средняя цена на туфли в этом магазине - $40-60. Что вы подумаете про туфли за $10 и туфли за $100? Наверняка дорогие автоматически покажутся вам лучше - качественней, долговечней, удобней в перспективе (должны же они за что-то брать эти $100!). Возможно, вы их не купите, потому что посчитаете, что переплачивать вдвое от средней цены - это уже слишком. Но купитие ли вы туфли за $10? Вряд ли. Логика тут противоположная: если они стоят так дёшево, значит с ними наверняка что-то так.

По поводу связи скилов и зп. Во-первых, есть некая градация на уровни специалистов, и работник может запросить только большую зп для своего номинального уровня. Например, пусть будет деление на junior, developer и senior. Джуниор может запросить зп равную верхней границе для джуниоров, чтобы показать, что он очень круто для своего уровня. Но если он запросит верхнюю границу для девелопера, то разрыв между знаниями и запрашиваемой зп будет слишком очевиден и ему однозначно откажут (туфли за $100).

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

Думаю, этого достаточно, чтобы убедиться, что скилы влияют на зп, но во время найма нельзя "продаваться за дёшево", поэтому дальше тему не развиваю.

Missing-male

Люди, которые запускают эти скрипты, ищут по ключевым для кандидата технологиями. Если скрипт по запросу "SQL" укажет (среди десятка прочих) на человека с заголовком профиля "Flex/Flash developer", то эти люди скорее всего пройдут мимо этого резюме, даже не заглядывая в полный профиль. Другое дело, если это то, чем вы гордитесь и хотите показать. Как я и написал в статье, если вы разработчик баз данных или просто бек-енд разработчик с упором на хорошее владение реляционными БД, то, естественно, SQL стоит указать.

В принципе, пункт больше относится к тем ключевым словам, по которым вас вряд ли будут искать. Я ни разу не видел, чтобы искали bash-программиста, или человека со знанием cron, или с опытом работы с STL. Искать будут по ключевым словам Linux/Unix, C++ и т.д., но не по bash, cron и STL.

Missing-male

Спасибо за дополнение! Очень верно сказано, и очень хороший пример. C++, как правило, считается хорошим навыком, даже если вакансия не предполагает никакой работы с этим языком, поэтому указать его стоит. Но если работали с ним, когда по земле ещё ходили динозавры, то выставлять его сверху не имеет смысла - вначале должны быть важные и всё ещё актульные навыки.

Missing-male

Ну, во-первых, подсознание к метафорам/аналогиям никакого отношения не имеет. По крайней мере согласно господствующим теориям.

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

Missing-male

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

Missing-male

Буду рад почитать! Можно в личку.

Missing-male

Эээ, ну я даже не знаю, какие пруфы можно привести, чтобы доказать, что осознаные продуманные аналогии создаются сознением, а не подсознанием. Определение из Википедии, может быть?

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

Missing-male

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

Missing-male
+5

Название статьи сильно отличается от оригинала.

Чего я понять не могу, так это что же всё-таки дало толчок такому количеству стартапов?

Большинство молодых людей, мечтающих стать стартаперами, почему-то не понимают нескольких важных вещей.

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

Во-вторых, стартап - это не быстро и не просто. Сил в него вкладывать надо гораздо больше. Вы планировали съездить на выходных за город? Забудьте! До вторника нужно полностью оформить такой-то модуль! Вы планируете отпуск в Испании? Ни в коем случае! Вдруг в это время нужно будет встретиться с инвестором! Я работал ни с одним, и не с двумя стартапами, и даже мне, как стороннему разработчику, приходилось пропускать выходные, чтобы ребята успели подготовить презентацию вовремя.

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

Missing-male

Ну обычно молодые и амбициозные болеют именно идеей стартапа, который принесёт миллионы.

Missing-male
+1

Весь back-end, если быть точным. По их же словам, упёрлись в плохую расширяемость RoR, а в Scala они нашли одновременно расширяемость, быстродействие и элегантность.

Missing-male

Извините, но статья вызвала жёсткую неприязнь. С чисто литературной точки зрения. С философских вопросов о RoR для крупных проектов вы резко перескакиваете на конкретные разработки (при этом упор делаете на смесь технологий, звонкие названия типа "NoSQL" и количество пользователей, а Ruby тут вроде как и не причём), потом резко выворачиваете на восхваление самого Altoros, и в конце посыпаете всё это описанием вакансий на пару с курсами. Я только с третьего прочтения понял, как всё это связано.

Missing-male

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

Missing-male
+2

Ещё одна книга из разряда the must - Structure and Interpretation of Computer Programs. Построена на MIT'овском курсе 6.001.

Missing-male

> 3) Проблема ИИ в общем случае не решена еще по причине отсутствия в настоящий момент достаточно мощного железа

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

С другой стороны, многие задачи решаются легче: ищется упрощённая, но достаточно точная модель, обучается и в итоге получается эффективная система, НЕ эмулирующая мозг и НЕ требующая таких больших вычислительных мощностей. Если я не ошибаюсь, вы занимаетесь обработкой (видео)избражений. Тогда вы должны быть в курсе, что такое признаки Хаара и какие они способны давать результаты.

Missing-male
+13

А это не совсем и юмор :) Если вы посмотрите обсуждение на форуме, то увидите, что люди не всегда понимают, что на самом деле значат статусы вроде "senior developer". Многие (действительно многие, не только на dev.by, но и в жизни) представляют себе обязанности разработчика высокого уровня как "писать чистый код, который будет просто поддерживать и рефакторить". Я попытался вот так схематично показать, что обязанностей на самом деле гораздо больше, и признаками уровня старшего разработчика является не только чистый код, но и умение самостоятельно решать задачи с опережением по времени (чтобы осталось время на фиксы, если чё), видеть систему за пределами своей конкретной задачи, оптимизировать свои модули или вносить предложения об измнениях на уровне архитектуры.

Missing-male
+3

It depends. Если вы знаете, что кофе варить приходится часто, и знаете, что в какой-то момент (например на утро после корпоратива) его может понадобится очень много, то не оптимизировать соответствующие механизмы будет практически преступлением. И да, я считаю, что такими вопросами должны заниматься именно старшие разработчики, а не архитектор или тим лид - ни у того, ни у другого просто не хватит "пропускной способности", чтобы отследить все такие моменты. Хотя конечно, если сеньёр хочет внести серьёзные измнения, то лучше всё же вначале поставить тим лида в известность.

Missing-male

Видимо, автор топика удалил его.

Missing-male
+2

Я склоняюсь ко мнению, что тим лид - это роль, а не статус. То есть по знаниям и умениям они примерно равны. Ну, разве что тим лид ещё с людьми работать должен уметь.

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

В любом случае, статья не о менеджерах или тим лидах, а именно о разработчиках и их уровнях - когда можно начинать считать, что человек достиг некоторого уровня.

Missing-male
+1

А там просто нужно было буковки по двоеточиям выровнять.

А если серьёзно, на StackOverflow и других сайтах этой сети при обсуждении статусов часто используют выражения "intermediate developer" или "professional developer". Первое показалось более понятным.

Missing-male
+2

Ок, в следующий раз напишу про процесс подготовки топ-кварков для фатонно-адронного столкновения младшими, средними и старшими сотрудниками большого адронного коллайдера. Такое сравнение вас устроит?

Missing-male
+5

Вячеслав, вы путаете функциональные требования и технические детали реализации. По идее из описания должно было быть понятно, что речь идёт о каких-то простых технических действиях типа создания простого контроллера или разбора JSON-сообщения. Или вы хотите, чтобы вам заказчик рассказал, какой цикл лучше использовать - for или while?

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

Missing-male
+3

Я надеюсь, что сеньёры после прочтения улыбнутся, вспоминая себя джуниорами, джуниоры поймут, к чему нужно стремится, а средние программисты сделают и то и другое :)

Missing-male

А ещё автор не умеет читать и писать, вы правы.

А причём тут опенсорс?

Missing-male

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

> С относительной точки зрения этот вклад ничтожно мал. Например, этот парень вкладывает гораздо больше http://dev.by/blog/46105

То, что делает парень - это, конечно, хорошо. Но это его личная инициатива, которая в случае чего будет иметь только его одного. Если вы руководите компанией, то за ваши решения поплатиться вся компания, в том числе ваши собственные работники, которые на вас рассчитывают, а это уже немного другое. В итоге мы имеем чёткое разделение между личным желанием творить благо и интересами компании. Я сам постоянно пытаюсь развивать IT образование, как внутри страны, так и в мире вообще, вкладывая своё время (а иногда и напрямую деньги) в написание статей, ответы на вопросы, прямое обучение студентов и т.д. Однако если речь заходит о проекте, я вынужден ставить задаче повышения уровня образования один из наименьших приоритетов, ибо в противном случае пострадает проект, пострадают люди, работающие со мной и люди, рассчитывающие получить нужный результат вовремя.

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

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

Missing-male

Да, вот только это ни разу не близко к функционалу jQuery (даже если брать чисто AJAX), а если приближать его к такому функционалу, то получится тоже немало текста. А размениваться на 50-10кб, которые после первого же запроса закеширует браузер, это довольно смешно.

Missing-male
+1

Ааа! Я только что посмотрел, куда ведёт ссылка на "код с подсветкой"! Вы его осознанно на говнокод.ру закинули или просто про другие сервисы для выкладывания кода не знаете? :)

Missing-male
+7

Начнём с того, что нигде в статье я не увидел обоснований, зачем разработчику НЕ быть "зомби". "Вы творцы!", "вы можете!" звучит так же, как "выполним план пятилетки за 4 года!". Упор чисто на энтузиазм самих разработчиков. Сами себя мотивировали, сами увеличили производительность. PROFIT? PROFIT получил менеджер и работодатель, но не разработчики.

И если уж говорить про энтузиазм, то для успешной работы команды он должен исходить от лидера (менеджера, тим лида, просто старшего разработчика - статус неважен, главное, чтобы это был человек, которого уважают и за которым готовы пойти). Лучшие менеджеры, с которыми я работал, говорили что-то вроде "we are so excited about this project! and we want to share the whole idea with you!". И это действительно впечатляло, позволяло почувствовать себя частью чего-то крутого. Тут же и чувство ответственности появлялось - когда понимаешь, что качество разрабатываемой системы зависит в том числе и от тебя, начинаешь по другому смотреть на свою работу. И уже не хочется уходить домой, если в 7 вечера вдруг срывается интеграция.

А вот фразы типа "найдите себе челендж" не впечатляют. Вообще.

Это во-первых. А во-вторых, повышение зарплаты, повышение по карьерной лестнице и вообще выход в лидеры слабо зависит от умения писать правильный код, засиживаться после окончания рабочего дня и т.д. Отношения с работодателем - это корпоротивные политические игры. Есть такое выражение: "Если система упала на пол часа, то ты - некомпетентный работник. Если ты её поднял спустя пять часов, то ты - герой". Чтобы получать хорошую зарплату, нужно постоянно держать работодателя в страхе, что ты можешь уйти. Естественно, это должно подкрепляться положительными результатами в работе, чтобы работодателю было что терять, но основным фактором повышения ЗП всё равно остаётся "игра" с начальством.

То же самое с повышением по карьерной лестнице и становлением лидером. Лидер - это не тот, кто пишет красивый код и следует всем паттерным проектирования. Как вы сами сказали, за рефакторинг никто не хочет платить, и по сути его даже никто не заметит (кроме, возможно, других разработчиков, но это не они вам платят и не они принимают решение о повышении). А вот что заметят, так это новые идеи, энтузиазм, да и вообще позитивный настрой при обсуждении проекта, например, на митингах. Позитивные люди с кучей идей вызывают доверие - это психология. Унылый профессионал имеет гораздо меньше шансов получить повышение до, скажем, тим лида, чем активный среднячёк. Потому что лидер должен вести, принимать решения, идти впереди и показывать дорогу, а унылый профессионал на такой должности с большой вероятностью просто застрянет, уйдёт в депресиию и завалит проект. Как-то так.

Missing-male

Как раз если кроме профита ничего не интересует, и есть кое-какие мозги, то как раз профит и подтянется. А если работа сама по себе уже в кайф, то о чём тогда вообще речь? Всё есть, менять ничего не надо.

Missing-male
+1

Абзац 1 относится сугубо к вашей статье. Вы нигде не описываете, почему разработчик должен хотеть расти над собой, если можно раз в год менять место работы и получать +30% к ЗП.

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

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

Абзац 3: прозвучало как "ты не хочешь бухать с нами? ты слобак!". Ну пусть слобак, зато печень цела. А челенджей у меня хватает и за пределами работы, и эти челенджы гораздо интересней, чем система логирования или очередной контроллер, которые вызывают скорее скуку, чем напряжённый умственный процесс.

Абзац 4: опять же, логика на уровне "открываешь дверь левой рукой? ты кирпич!". Ну или как те же советские лозунги - "слушаешь джаз - туниянец и предатель родины!". Почему я не могу слушать джаз и любить родину одновременно? Почему я должен выбирать между программированием и хорошей зарплатой?

Абзац 5: и снова вы зачем-то переворачиваете мою логику. Вы говорите: "пашите как рабы на галерах и через 10 лет станете менеджером!". Я отвечаю: "повышение до менеджера слабо связано с упорной работой, решающими факторами являются совсем другие вещи". Вы: "да ты не хочешь реализовывать свои идеи! ты зомби!". Ну и как это связано?

Missing-male
+2

> Вы никогда не станете самым крутым даже (или тем более ?) в бизнесе

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

> Вам будет все время хотется подняться над собой, перейти на новый уровень (творческий, професииональный).

Ну ок, не вопрос, а статья то тут причём? Или основная мысль статьи как раз и сводится к одному слову "творите"?

Missing-male
+2

> Мдя, почему-то на девбае статья воспринимается как руководство по переходу в ПМы. Я же АБСОЛЮТНО не об этом пишу. Я НАОБОРОТ пишу о том, как горизонтально расти, как становиться ХОРОШИМ программистом, простите за капслок.

Как расти? Сидеть на работе после 7 вечера и искать челенджы в очередном типовом контроллере?

И главное, зачем расти? Не, я то знаю, зачем мне расти - меньше времени, больше денег, уважение коллег (4-ая ступень пирамилы Маслоу, как никак), возможность самостоятельно выбирать, над чем работать и т.д. Но в статье я не вижу ничего об этом. А вижу я только "растите над собой, потому что от этого вашему работодателю будет хорошо". Извините, но после этого я наоборот хочу стать зомби.

> Если бы разработчик, который не понимает, как на качество продукта влияет его труд, хотя бы раз в полной мере ощутил на себе последствия своего позуизма, то у него бы больше не возникло вопроса об общей картине [...] Знаете, сколько раз я давал полную картину всяким идиотом, от чего они становились еще большими идиотами?

Ну не давайте общую картину, расскажите работникам, как их работа поможет бедным детям африки искать воду на их айфонах, или какое уважение они получат от open-source сообщества, или хотя бы какой шикарный банкет обещал директор на следующий день после сдачи проекта. Если вы хотите мотивировать работников, это гораздо эффективней, чем сказать им "развивайтесь!".

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

Человек либо получает удовольствие от хорошо проделанной работы, либо не получает. Опять же, как на это должна повлиять статья?

> Не знаю, где я там про "бухать" говорил. А вот продолжением ведь вы подтверждаете, что вы зомби)) То есть, вам не интересно быть программистом, потому что если бы было интересно, вы бы так не писали, нет?

"Бухать" - это метафора. В вашем случае это "не хочешь стать хорошим программистом? да ты зомби!". Ну ок, я зомби. Мне теперь должно стать стыдно или что?

Эээ, а с чего вы взяли, что челенджи за пределами работы не связаны с программированием? Наоборот, за пределами работы как раз и встречаются самые интересные инженерные челенджи. Я вот сейчас работаю над системой автоматического распознавания эмоций на лице человека по видеоизображению. Это - челендж. А написание очередного веб-приложения - это не челендж, это скучная монотонная работа.

> Вас никто не заставляет выбирать между удовольствием и зарплатой. Я говорю о том, что если, как ниже написал Сергей, вы мотивируете нежелание выкладываться на работе только отсутствием оплаты - вы уже зомби.

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

> Вы щас сами с собой спорите, смотрите, что я в этой мессаге в самом начале написал.

Где я с собой спорю?

Missing-male

Зачем? Вы сами написали, что есть "первый путь", где можно не особо напрягаясь повышать ЗП на 30% в год.

Missing-male

> Примерно так на мой взгляд :)

Ну тогда, как уже говорил выше, не впечатляет. Хочу быть зомби :)

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

Missing-male
+1

Вы много знаете программистов-миллионеров? Вот именно программистов? Я - ни одного. Зарплата программиста всегда ограничена какой-то планкой. Планка довольно высокая, но не на миллион. Чтобы перейти эту планку, нужно быть собственником бизнеса, крупным акционером, директором или кем-то таким. Это не значит, что из программиста не может получится миллионера - тот же Цукерберг когда-то был простым студентом-девелопером, но реально большие деньги он стал получать после создания своего бизнеса. Даже если вы делаете милионный проект и занимаетесь исключительно разработкой, то за вами всё равно стоит ваш партнёр или инвесторы, а вы автоматически стоновитесь соучередителем. А так даже зарплаты инженеров Google и Facebook редко превышают $120-140k в год.

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

Missing-male

Вы не ответили - так зачем? Чтобы не называться "зомби"? Не серьёзно.

Missing-male
+8

Выхватил из текста фразу "ЖЭС вечен" и чуть со стула не свалился.

Missing-male
+1

> Отец говорит сыну...

Сразу вспомнил историю с баша, когда инженер-рокетчик с высшим образованием и работающий по специальности, подрабатывал по выходным таксистом. И вот как-то садиться к нему в машину мамаша с ребёнком. Ребёнок кричит, не слушается, а мамаша ему:

- Будешь плохо себя вести - не поступишь в институт и будешь работать как дядя, таксистом!

Missing-male
+5

Так вот, почему я всё-таки не люблю слово "творчество" применительно к программированию. Потому что как раз творчества в программировании нет. Вообще. То, что обычно называют творчеством на собеседованиях и etc. на самом деле является самоактуализацией (http://ru.wikipedia.org/wiki/%D0%A1%D0%B0%D0%BC%D0%BE%D0%B0%D0%BA%D1%82%D1%83%D0%B0%D0%BB%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F). Творчество предполагает создание чего-то нового, уникального и неповторимого, основанного на личности автора. Т.е. если посадить двух художников и попросить их нарисовать дерево, они нариуют его совершенно по разному. А вот если посадить двух программистов и дать им спецификацию программы, которую нужно написать, то результаты их работы наверняка будут очень похожи.

Правда, с помощью программирования можно творить - например, создать новую, уникальную и неповторимую игрушку под Андройд, или даже просто flash-баннер - но творчеством в данном случае является сама идея игрушки или баннера, а программирование - это просто инструмент реализации.

Тем не менее, программирование позволяет удовлетворить многие другие потребности человека. Если брать за основу классическую пирамиду Маслоу, то на примере работы программиста можно продемонстрировать все её уровни. Напомню структуру пирамиды (от нижнего уровня до верхнего):

1. Физиологические потребности (пища, сон, секс).

2. Потребность в стабильности (крыша над головой, уверенность в завтрашнем дне).

3. Потребность в общении.

4. Потребность в уважении и признании.

5. Потребность в самоактуализации.

Кроме того, в оригинальной пирамиде (именно пирамиде - она была построена позже, сам Маслоу просто выделял уровни без интерпретации структуры) по бокам располагались 2 дополнительные колонки, которые были актуальны для людей, находящихся на всех уровнях пирамиды - это стремление к познанию и стремление к систематизации. С познанием понятно - даже если вы голодны, вас всё равно будет интересно, кто вчера выиграл в футбол. Систематизация - это упорядочивание, структуризация, придание более правильной формы. Жена, приходя домой вечером, уставшая и злая, видя разбросанные ребёнком игрушки, всё же не идёт сразу на кухню или в кровать, а начинает убирать их. Потому что отсутствие упорядоченности и структуры причиняет ей дискомфорт.

Так вот, применительно к программированию.

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

3й пункт, как правило, тоже удовлетворяется с лихвой за счёт общения с коллегами. Исключение составляют разве что фрилансеры, да и те всё чаще объединяются в стайки и занимаются коворкингом.

С 4-ого пункта начинается интересное: уважение - это уже гораздо более дорогой товар, нежели просто общение. А за признание многие реально готовы пахать сутками напролёт (при условии удовлетворённости первых трёх уровней пирамиды). Уважение и признание - это очень сильные мотиваторы. Фразы вроде "I'm so happy to work with you!" сразу заставляют чувствовать себя значимым и уважаемым, а значит дают +10 к настроению и +20 к авторитету менеджера.

Далее - 5й уровень и самоактуализация. Вообще-то сама структура пирамиды Маслоу предполагает, что до этого уровня добирается не так много людей. Однако каста разработчиков отличается особой зажратостью, поэтому относительно много людей имеет возможность удовлетворить потребность в самоактуализации. Самоактуализация предполагает развитие. Джуниору легко самоактуализироваться - для него любой таск - это развитие, что-то новое и интересное. Чем старше разработчик, тем труднее ему найти интересную задачу. Все мы в какой-то мере доктора Хаусы, которые как дети отлынивают от скучных тривиальных проблем. Можно сколько угодно говорить ему "заинтересуйся проблемой!", но он как зевал при её виде, так и продолит зевать. Если уже не уснул, конечно.

Поэтому нужны какие-то хитрости, обходные пути, чтобы вернуть его интерес. Можно рассказать про конечную цель системы ("с этой программой мы сможем добиться честных выборов!"), можно впечатлить разработчика техническими деталями ("25 серверов, обрабатывающих до 30Тб данных в сутки!"), можно добавить в команду суперзвезду программирования, чтобы все равнялись на него и видели, куда ещё им расти. В конце концов, можно взять тупо харизмой. Есть много вариантов. Лично я, как разработчик, чтобы не терять интерес к проекту иду на хитрость - начинаю параллельно свой маленький проект. Переключение на другой проект работает как активный отдых - вроде и что-то полезное сделал, а вроде и к основному проекту интерес снова возрос. Но это я так для себя делаю, ожидать, что все станут сами себя мотивировать, да ещё и производительность при этом не потеряют, всё-таки не стоит.

С дополнительными "колонками" пирамиды тоже всё достаточно ясно: если разработчик ещё не утратил способность учиться, то познание нового (новых фреймворков, новых языков, новых областей computer science) является для него постоянной потребностью, и с точки зрения менеджера про неё также не следует забывать. То же самое с систематизацией и структурированием - программисты при виде "грязного" кода ощущают такой же дискомфорт, как жена, видящая разбросанные по всей комнате детские игрушки. (А теперь, господа менеджеры, представьте, что чувствует программист, которому не дают сделать "уборку" ;)).

На мой взгляд, это достаточно полная модель потребностей разработчика ПО. И, как видите, в ней нет ничего связанного с творчеством. Эта же модель позволяет мне думать, что лозунги типа "если не приносишь компании пользу - ты зомби" не будут работать. В советские времена она работала за счёт 3-его и 4-ого уровней пирамиды - люди, которые НЕ велись на лозунги, были изгоями и находились в своеобразной изоляции: с ними не общались, и, конечно же, их не уважали. Сейчас, когда людей, НЕ ведущихся на лозунги, большинство, последние тупо теряют смысл.

Missing-male

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

Missing-male
+1

> Не интересовался, но допускаю, что капиталы некоторых однокурсников-одноклассников-эмигрантов уже за 6 цифр перевалили. Думаю, вполне к пенсии на 7 цифр выйдут.

Я почему-то сразу подумал про белорусские деньги :)

Даже при гуглевской зарплате в ~$120k в год и жёсткой экономии с конечными затратами $20k на то, чтобы заработать миллион, уйдёт 10 лет. Я полагаю, понятие миллионера (т.е. человека, при упоминании которого в первую очередь думают про его финансы) предполагает несколько иной сценарий.

Missing-male

Нет, определённо пора завязывать с длинными комментариями.

Missing-male
+1

Дело не в том, нужен сильный лидер или нет - я прекрасно справляюсь и без него и даже могу занимать его место, если более подходящих кандидатов нет. Дело совсем в другом. Интерес разработчика к проекту складывается из ряда параметров (каких именно - см. ниже). Один мой хороший знакомый как-то, увольняясь с работы, сказал: "В компании можно оставаться ради одной из двух вещей - деньги и люди. Если не удовлетворяет ни то, ни другое - смысла оставаться нет". На самом деле факторов гораздо больше, но смысл (как для самой работы, так и для конкретного проекта) примерно тот же.

Про параметры и "творчество" следующим ответом.

Missing-male

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

Missing-male
+1

1. Если брать в расчёт субъективное восприятие, то да, соглашусь с вами - некоторая доля творчества в программировании есть (приятно общаться с людьми, которые могут подвинуть моё устоявшееся мировоззрение :)). Тем не менее, эта доля обычно довольно небольшая. Я бы сказал, что само по себе программиование - это на 30% познание (попробуйте у программиста забрать гугль - насколько упадёт его производительность?), на 40% - структурирование и систематизация, на 20% - самоактуализация за счёт саморазвития и только на 10% - за счёт творчества. С цифрами можно спорить, но всё равно программирование - это не та "творческая профессия", о которой так любят говорить HR-ы на собеседованиях. Есть чёткие инженерные критерии хорошей программы, сильно ограничивающие "творческую свободу". Сравните, например, с музыкантами: если им продюссер говорит, что в этой песне нельзя использовать мат, то они сразу обижаются и говорят, что им мешают творить. А программисты ничего - воспримают это как что-то абсолютно нормальное (и только расстраиваются, что им опять не дали изучить интересный фреймворк :)).

2. Ненене, хитрости - это не к самоактуализации относилось, это просто пояснение к предыдущим комментариям. То есть я хотел показать, что есть куча способов мотивировать работников коме "лозунгов". Про лозунги я уже тоже спорил с ТС, пытаясь выяснить, что в его посте должно заставить разработчиков развиваться. Единственный выраженный аргумент, который я слышал - это "вашей компании будет лучше". А это очень похоже на лозунг. В итоге я сам его мысль в целом понял, но хорошей формулировки так и не добился. Как-то так.

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

P.S. А я то думаю, вроде бы ж была уже такая мысль в треде!

Missing-male

Мне кажется, "потребность в справедливости" сводится к другим потребностям, таким как потребность в уважении. Бил Гейтс вон постоянно твердит студентам: "Запомните раз и навсегда - мир несправедлив!". И ничего, прекрасно ведь себя чувствует.

Missing-male

1. Не, ну так музыкантам же никто не мешает взять вместо гитары, скажем, трамбон, или вообще разбавить музыку визуальным перформансом. А программерам - очень даже :)

2. Ну вот я и пытался выбить что-нибудь такое, а ТС про компанию, да про компанию.

Missing-male

А вот с выбором языка, обычно, всё гораздо сложнее. Я знаю кучу людей, в том числе в Минске, которые мечтают писать на чём-то другом, но руководство им не позволяет (взять то же сообщество scala_by). Иногда, потому что заказчик хочет результат на чём-то определённом, иногда - потому что работодатель боится, что потом не найдёт других людей, способных в случае чего заменить данного работника, иногда ещё что-то. Так что в большинстве случаев выбор таки сильно ограничен.

Missing-male

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

Missing-male

А вы действительно считаете их работу творческой? ;)

Missing-male
+3

Weak References - объекты удаляются при первой же сборке мусора после того, как исчезли все остальные ссылки на него. Use case: создание некоторого объекта занимает много времени, при этом его требуется создавать из многих мест кода, но держать в памяти все такие объекты слишком затратно. В этом случае можно создать кэш на основе Weak References - пока хотя бы где-то объект используется, к нему можно будет достучаться через кэш и не создавать заново. Как только все ссылки исчезли, объект удаляется.

Soft References - объекты удаляются только после того, как исчезли все сильные ссылки _и_ программе стало не хватать памяти. Use case: все остальные типы кэшей, но, как и написано в JavaDoc используются либо для очень простых кэшей (т.е. не подходят для высоконагруженных приложений), либо как составная часть более эффективных кэшей (в т.ч. на основании LRU).

Missing-male
+3

За анализ спасибо, но всё-таки есть ряд недочётов.

Во-первых, проектирование кэша - это далеко нетривиальная задача. Если человека, который может додуматься реализовать кэш просто через HashMap, допустили к высоконагруженному приложению, то это уже ошибка на уровне менеджмента. В принципе, это касается и LRU с Weak/Soft References - в первом случае разработчик должен хорошо разбираться в многопоточности, во втором - в управлении памятью в высоконагруженных системах.

Во-вторых, проектирование кэша должно начинаться с изучения потоков данных: какие именно объекты чаще всего требуется кэшировать, как долго они "живут" и т.д. И уже в зависимости от этого решать, как лучше всего спроектировать кэш - ограничивать время жизни объекта размером кэша или просто временем, держать его в мэпе или массиве, или вообще использовать кэш БД.

Во-третьих, вы нигде не упоминаете, что процесс управления памятью можно настраивать. В частности, существует не одна, а несколько приличный реализаций JVM, в каждой есть несколько стратегий сборки мусора, для каждой стратегии есть масса опций управления поколениями. На многопроцессорных машинах можно спокойно использовать cuncurrent low pause collector, который большую часть сборки мусора делает без остановки выполнения приложения. Если на этапе исследования потоков данных вы заметили, что большая часть данных читается из кэша, то можно уменьшить young generation ("дети" в вашей терминологии) в пользу tenured generation ("взрослые"), в котором и будет хранится кэш. Ну и так далее.

В общем, вариантов много. Конечно, все они требуют понимания процесса управления памятью на соответствующей платформе (и виртуальном машине), но разве проектирование кэша, скажем, на C++ этого не требует?

Missing-male

Переход к автоматическому управлению ресурсов - это сдвиг парадигмы, а не запрет на что-то там. При желании на той же Java или C# можно и ручное управление памятью устроить, и арифметику указателей, и всё что угодно. Но только вот менеджмент ресурсов в условиях развития многопоточных программ быстрее и проще оказывается как раз на языках со сборщиком мусора.

Missing-male
+1

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

Дальше бред. Не знаю, с какого перепугу в Java вдруг стало не нужно думать про память. Ресурсы есть ресурсы, про них в любом языке думать надо. Если вы про то, что не надо делать ручное удаление объектов, так это тоже неверно - утечки памяти в managed языках встречаются реже, но всё-таки проскакивают (кэш на HashMap - хороший пример).

Откуда вдруг появились скриптовые языки тоже непонятно. Или это вы так Java с C# обозвали?

Missing-male
+1

Приятно, что на этом форуме есть люди, с которыми не соскучишья ;) И чего же я, по вашему, не понимаю? Пока что я не понимаю только откуда вы взяли идею о том, что в managed языках не надо думать про память, и зачем вы же сами её пытаетесь опровергнуть.

Дальше тоже весело. Для начала дайте определение скриптовым языкам, только учтите что:

- 99% современный реализаций языков на каком-то этапе компилируются в нативный код, в том числе такие языки как Python и даже JavaScript;

- прекомпилированные файлы многих "скриптовых" языков (например, Python) непереносимы между платформами;

- компиляция кода на C++ может происходить в несколько этапов (так же, как и в Java/C#) например, через LLVM;

- на Java и Sing# написаны операционные системы;

- "скриптовый" Perl на порядок сложней "компилируемого" C++;

- на высокоабстрактном Lisp'е можно программировать микроконтроллеры.

Сможете после этого провести линию между "скриптовыми" и "компилируемыми" языками?

Missing-male

То есть кэш, о котором у вас статья, - это не real-life use case? :) Слабые ссылки - это не то, что вы будете использовать каждый день. Есть достаточно узкий класс задач, для которых и придумали эти типы ссылок. И в основном эти задачи сводятся либо к кэшам (общее хранилище некоторых объектов, подлежащих удалению при длительном неиспользовании), либо к парам связанных объектов. Например, вам требуется для некоторых объектов хранить метаданные, такие как их источник или строка документации и т.д. Если объекты могут быть разного типа, а дополнительная информация есть только для небольшого подмножестве всех объектов, то совершенно нет смысла добавлять лишнее поле - гораздо эффективней будет создать мэп, в котором ключом будет объект, а значением - метаданные. При этом если некоторый объект в программе больше не используется, то его метаданные также следует удалить. Идеальным решением как раз и будет какой-нибудь WeakHashMap, который позволит явно добавлять и проверять метаданные и самостоятельно позаботится о том, чтобы объекты после использования не засоряли память.

В Scala, кстати, есть похожая фича - traits, дополнительные данные или функциональность, которая может примешиваться (mixin) как к классам, так и к индивидуальным объектам.

Missing-male
+2

> Откуда идея...да пожалуйста. Читайте, как хотя бы жабу официально позиционируют:

Ну и? Единственная строчка про память там: "automatic garbage collection helps you avoid memory leaks". Прочитайте ещё раз: Java _помогает_ избавиться от _утечек памяти_. Помогает, а не гарантирует, и от утечек памяти, а не от необходимости думать про память вообще. Так что не читайте больше, чем написано, а лучше вообще думайте своей головой.

> Отдельные исключения, граничащие с извращениями, приведенные вами, лишь подтверждают правило.

Ну нихрена себе извращения, простите за мой французский! Я вам назвал языки с верхних строчек рейтингов популярности и их стандартные реализации, то, чем пользуются миллионы людей. Конечно, если вы как монашка сидите за стенами C++ и считаете всё остальное ересью, то я не собираюсь трогать ваши религиозные взгляды. Но скажу по секрету - там за стеной много интересного ;)

> Вообще, вижу что вы не поняли :)

Нет, то, что вы считаете Java медленной неповоротливой кувалдой - это я понял. Я не понял, откуда вы взяли это мнение. Даже в 95-ом году Java не была кувалдой, а сейчас с развитием JVM и самого языка она стала вполне себе тонким инструментом. Не хирургическим скальпелем, конечно, но домашним ножом так точно.

Missing-male
+1

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

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

> Настройка GC может дать некоторый положительный эффект, но она не поможет в решении главной проблемы - линейной зависимости времени работы GC от количества объектов в памяти, т.к. любой GC, основанный на mark-and-sweep, имеет алгоритмическую сложность O(количество_объектов_в_памяти).

Время работы любого менеджера памяти линейно зависит от количества используемых объектов. Я так понимаю, вы имеете ввиду тот overhead, который порождает проверка всех живых объектов. Но это тоже ооочень широкий вопрос, который нужно решать на уровне конкретной задачи. Где-то поможет пул объектов (за счёт снижения количества объектов, попадающих в старшее поколение), где-то low pause collector (который большую часть работы будет делать без остановки приложения), где-то ещё что-то.

Вы привыкли к менеджеру памяти а-ля C++, поэтому вас раздражает, что цикл сборки мусора может занимать много времени. Меня же раздражает, что процесс поиска куска памяти под новый объект - это не просто увеличение указателя, а тоже сложный процесс. Для вас костылём является разделение памяти на поколения, для меня костыли - это RAII и auto_ptr. Ну и так далее.

Факт в том, что современные программы имеют тенденцию порождать большое количество недолго живущих объектов и использовать многопоточность. И в таких условиях автоматическая сборка мусора а-ля JVM/CLR выглядит весьма привлекательной с точки зрения производительности. Если между сборками мусора вы породили 1000 объектов, а в живых осталось только 10, то обойти и скопировать эти 10 и зачистить все остальные будет быстрее, чем удалять все 990 объектов вручную и фрагментировать тем самым память. Многопоточность, которая делает бесполезным auto_ptr, заставляет либо писать какую-то мега хитрую схему управления памятью (сравнимую с использованием массива байт в Java), либо идти на компромисс и терять производительность (в C++11 появился shared_ptr, но и он не идеален - для его работы всё равно приходится запирать себя в рамки RAII). Это дилемма любого языка программирования: задачи, для которых этот язык был создан, решаются просто и эффективно. Более редкие для этого языка задачи тоже решаются, но либо не очень эффективно, либо не очень просто. В том числе это касается и кэша на Java.

> В языках программирования без поддержки автоматического GC процесс управления памятью обычно лежит на поверхности, а не запрятан глубоко в дебрях платформы :) Это позволяет лекго минимизировать неявные зависимости между кодом программы и платформой, на которой этот код исполняется, тем самым снижая количество различных WTF'ов типа тех, что описаны в статье. На java с .net с этим сложнее.

Простите, но в случае HashMap и WeakReferences единственный WTF-ом для меня была сама идея их голого использования в виде кэша. В случае с LRU я так и не увидел серьёзных проблем (по крайней мере для маленьких и средних кэшей). Ну и да, на C++ особенности управления памятью в критических условиях (весь объём оперативки, своп, конкуренция с другими приложениями) отнюдь не выглядят для меня простыми.

Missing-male

> Вообще-то кэш по определению не обязан хранить объекты до истечения их времени жизни.

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

> Хм, странное мнение. Я всегда думал, что при сильной перегузке, с которой сайт не в состоянии справиться (DoS атаке или хабраэффекте), будет лучше, если некоторые пользователи будут "вылетать"

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

> Автоматический сборщик мусора типа mark-and-sweep должен периодически посещать все объекты в памяти, даже если они очень редко используются программой [...] Таким образом, количество объектов в памяти никак не влияет на производительность программы при ручном управлении памятью - будь их 10 тысяч или 10 миллиардов.

Ну почему же не влияет - а как же фрагментация, как же локи на многопоточных системах. malloc/mmap тоже и не идеальны, и не всегда предсказуемы, и такие общие рассуждения без знания данных и запросов - это всё ещё изучение сферического коня в вакууме. Например, из внезапно пришедшего миллиона пользователей сколько процентов будут активно использовать сайт, а сколько можно будет засунуть в своп? Для абстрактного проекта ни вы, ни я этого предсказать не можем. И если активных пользователей окажется 90%, то никакое ручное управление памятью вас не спасёт от постоянных обращений в своп.

Впрочем, это уже ремарка. Я вашу идею понял, думаю, вы мою тоже :)

Missing-male
+2

Ооой, опять какая-то каша понятий.

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

Во-вторых, любой из названных языков работает на целом стеке виртуальных машин. C++ сразу опирается на железо? А память вы тоже сразу на железе выделяете, или всё-таки запрашиваете у виртуальном машины операционной системы? Да и на более низком уровне вы не опираетесь на логику железа - вы опираетесь на виртуальную машину архитектуры процессора (и других элементов, но процессор особенно показателен). Детали того, как реализованы конкретные операции процессора от вас всё равно скрыты. И даже процессор не является самым низким уровнем абстракции - есть транзисторы, есть логические элементы и так далее вплоть до физических свойств используемых материалов.

Так в чём тогда кардинальное отличие JVM/CLR? В том, что они ставятся поверх операционной системы и поэтому создают дополнительный слой абстракции? Ну так возьмите соответствующие операционные системы, которые ставятся на голое железо. В том, C++ ближе к железу? А к какому железу? Попробуйте пописать на C++ для компьютеров Эльбрус, Лисп-машин или хотя бы микроконтроллеров.

JVM и CLR - это один из видов виртуальных машин, предоставляющих некий набор гарантий для вычисляющихся на них программ. Установка поверх ОС сделана всего лишь для удобства, с точки зрения языка такие ВМ - это полноценные операционные системы со своим набором инструментов.

В-третьих, вы пытаетесь пустить под одну гребёнку языки вроде Python и вроде Java. Python (будь то CPython, IronPython или какая-то ещё реализация) тоже оптимизируют, но основной идеей в нём была и остаётся простота и скорость разработки. Простота и _скорость разработки_. Сколько времени у вас уйдёт на то, чтобы на C++ написать паука по вебу? На Python - пару минут. И пока вы на C++ будете заканчивать класс для скачивания страниц, ваш конкурент-питонист уже запустит свой коммерческий сайт и оставит вас с носом. Использование медленных инструментов разработки ведёт к потере бизнеса. В этом смысл использования более простых и медленных языков типа Python.

Но мы говорим не про Python, мы говорим про Java. Java изначально позиционировалась как переносимый куда угодно язык, но никто никогда не говорил, что она должна быть медленной. Изначально также заявлялось про простоту, но это была простота относительно того же C++, но далеко не та простота, которая есть в Python. На сегодняшний момент Java вполне сравнима с C++ как по скорости, так и по сложности. Просто другая виртуальная машина, не более того.

В четвёртых, а изощрения типа jalloc, tcalloc, auto_ptr/unique_ptr/shared_ptr лишь бы иметь под рукой delete у вас не вызывают ощущения сюра ;) Причём GC меняет только внутреннюю структуру, а все эти инструменты требуют изменения кода.

Missing-male
+2

Нет, ну как об стенку горохом.

> Ну вот хоть на википедию сошлюсь... там это называется "Интерпретатор компилирующего типа" (http://ru.wikipedia.org/wiki/Интерпретатор).

Определение написано на редкость криво, но даже оно не ставит знака равенства между интерпретатором и виртуальной машиной: интерпретатор предоставляет ВМ для вычислений, но ВМ не сводятся к интерпретаторам. Определение виртуальной машины с той же википедии (http://ru.wikipedia.org/wiki/Виртуальная_машина):

спецификация некоторой вычислительной среды (например: «виртуальная машина языка программирования Си»)

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

Давайте вы для начала почитаете про процесс работы JVM, а потом уже будете делать какие-то утверждения, а то мне уже порядком надоело рассказывать прописные истины. Ни одна мало-мальски серьёзная реализация JVM на сегодняшний день не занимается чистой интепретацией байт-кода - Just-in-Time компилятор очень быстро переводит любые часто используемые функции прямиком в машинный код. Да-да, в машинные инструкции, которые идут сразу на процессор. В том числе на вашем компьютере с вашим обычным процессором. Представляете как неожиданно?

> Далее вы почему-то захотели обозвать ОС виртуальной машиной. Давайте посмотрим.

Для исполняемых файлов (таких, как *.exe в Windows) полной виртуальной машиной является совокупность ОС и процессора. Так уж исторически сложилось. Плюсов в этом я не вижу. JVM и подобные ВМ предоставляют более полный и завершённый уровень абстракции.

> 1. Интерпретирует скомпилированный код

Уже говорил выше.

> ОС, как библиотека времени выполнения, не пытается умничать и скрыть сложность задачи. Это полноценная, честная библиотека где вы имеете полный контроль над тем, с чем работаете.

Да что вы говорите! К планке оперативной памяти вы, наверное, напрямую обращаетесь? И в устройства ввода/вывода тоже без помощи ОС и драйверов, прямо так набором сигналов по соответсвующим протоколам пишите? И режим у вас не защищённый, а самый настоящий реальный, так что ли? Операционная система скрывает от вас детали реализации железа точно так же, как и JVM, странно что вы этого до сих пор не осознали.

И хватит уже нести чепуху про "центральную идею Java". Как уже было сказано выше, C в разы проще Java, так почему к C вы такое заявление не применяете?

> И да, предположим есть процессор умеющий исполнять компилированный код JavaVM... напишите вы ОС чисто на Java?

Адский ад. Во-первых, я уже написал, что на Java существуют операционные системы. Во-вторых, если сомневаетесь в чистоте той Java, почитайте про Oberon (Oberon, Bluebottle и ещё пара-тройка имён) - операционную систему, написанную на одноимённом языке программирования со сборщиком мусора. Сам язык написан на самом себе методом раскрутки (базовая часть языка написана на ассемблере, остальная часть - последовательными инкрементными доработками на самом этом языке). И ничего, сделали же как-то GC. Неожиданно, да? В-третьих, хватит уже считать, что в C/C++ вы напрямую работаете с памятью - модель памяти, которую вы используете, предоставляет вам операционная система. Или вы думаете, что mmap и malloc - это такие специальные сигналы на планке оперативки? Системные вызовы / API операционной системы - это точно такой же уровень абстракции над железом, как и сборщик мусора, просто другая модель предоставления доступа. Не больше, не меньше. И да, построение одной модели поверх другой может быть решено вполне эффективно и без серьёзной потери производительности.

> И не надо иллюзий, не сравнима жаба по скорости с С++ и по сложности. Иначе миллион хомячков... и все такое :)

Про сложность - почитайте не досуге про EJB, особенно про вторые, и сравните сложность. Про скорость - погуглите, посмотрите бенчмарки - узнаете много нового. Я уже когда-то на форуме приводил примеры, где C# обгонял по производительности C++, для Java, думаю, тоже не составит труда найти достойный пример. (А ещё лучше возьмите сразу Clojure, который вроде как по всем признакам должна проигрывать по скорости Java, но который на многопроцессорных системах зачастую работает на порядок быстрее.)

Missing-male

> А зачем тогда вот эта статья про костыли? :)

Про то, что для кого кажется костылём, я уже говорил здесь в комментариях.

> Вообще, если Java вся такая из себя хорошая, почему все более менее серьезные вещи весь мир пишет на С/С++?

Это вы так пошутили, да? Вы много сайтов на C++ видели? На PHP, Python, RoR - дофига, более серьёзные системы обычно на Java. Десктопные приложение под винду сейчас все переползают на .NET, кроссплатформенные - все на Java. И не надо свой негативный опыт использования отдельных программ на Java 10 лет назад переносить на весь набор современных Java-программ: даже последняя версия Intellij IDEA - одна из самых навороченных и многофункциональных программ на Java - летает даже на средненьком современно компьютере.

> И вот эта вот ссылка, которую приводил товарищ выше тоже не аргумент наверное?

> Гугль наверное для вас авторитет:

Нет, ну вы меня либо не слушаете, либо сознательно отказываетесь думать. Я где-нибудь говорил, что Java безусловно и во всех ситуациях работает быстрее C++? Не-а. Более того, я уже указывал на конкретные условия, при которых сборщик мусора начинает выигрывать у ручного управления памятью, в т.ч. многопоточность и порождение большого количества недолгоживущих объектов. И что же вы? Приводите частные примеры того, как C обгоняет Java? Хотите контр пример? Есть такой замечательный язык Clojure, построенный на JVM. Сам язык ещё молод, его реализация во многих местах использует довольно неэффективные методы, поэтому в целом он в несколько раз медленней Java. Однако в нём есть такая замечательная фича, как транзакционная память, позволяющая синхронизировать потоки без явных локов (т.е. по сути без необходимости постоянно синхронизировать кэш-линию, в которой лежат данные). И есть демонстрационная программа Ants, активно использующая распараллеливание. Так вот, на многопроцессорных машинах версия на Clojure с траназкционной памятью запросто бьёт по производительности версию на Java с явной синхронизацией. Сравнения с С++ не видел, но учитывая, что механизм синхронизации кэша в Java и C++ всё равно один и тот же, результат наверняка будет таким же. Не верите? Проверьте сами.

> Ладно, я чувствую запах религиозного фанатизма, поэтому давайте с этой темой закругляться

Вот над этой строчкой особенно смеялся, учитывая, что я тут выступаю за инженерный подход к выбору лучшего инструмента, а вы так фанатично держитесь за C++ ;)

Missing-male

> Очень странно что scala делает java по производительности, ведь все та же JVM.

Смотря на каких задачах, я бы сказал в 50% случаев быстрее Java, в 50% - Scala. Опять же, из-за разницы в подходах - где-ты выигрывает состояние, где-то - его отсутствие и финальные переменные.

Missing-male

Молодой человек, подучите матчасть для начала. В Java кроме synchronized есть volatile и атомарные операции, Scala строит многопоточность на акторах, в Clojure в добавок к этому есть Software Transactional Memory. Вы знаете другие методы синхронизации кроме этих и основанных на них?

> просто покажите мне веб-сервер на Java который работает быстрее чем Apache/nginx

Мне вот просто интересно, каким образом вы проводили сравнение? Вы проверяли, как бытро Apache отображает JSP-страницы, или как Tomcat/Jetty/JBoss обрабатывает PHP-скрипты? Это разные программы с разной функциональностью. И как-то я не слышал, чтобы кому-то не хватало для его задач скорости работы Tomcat.

> агада. вы вообще видели заголовки stdlib?

И что я там должен был увидеть?

> да и кстати. вот уж о производительности EJB помолчали бы :)

А я про их производительность ничего и не говорил, не читайте больше, чем написано. EJB - это огромный монстр с непомерными запросами на ресурсы и колоссальной сложностью, и мне трудно представить ситуацию, в которой я хотел бы их использовать. Речь шла о сложности, и, к сожалению, Java the world по сложности уже вполне сравнима с C++.

> MBA late 2010

Я понятия не имею, что такое MBA, если, конечно, это не Master of Business Administration и не MacBook Air. Будьте добры, поясняйте, о чём говорите.

Missing-male

Эээ, я так понимаю, вы спрашиваете, зачем Java, если есть PHP, так что ли?

Missing-male

Короткий ответ - потому что на Java некоторые задачи решаются проще, чем на PHP. Пример - любое приложение со сложной бизнес-логикой.

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

Missing-male
+1

Стандартный вариант загрузки страницы с фичами соц. сетей:

1. Пользователь обращается к PHP-скрипту.

2. Сервер начинает генерацию HTML-страницы из PHP-скрипта.

3. Поскольку скрипт содержит ссылки на API социальных сетей, сервер обращается к этим сетям и ждёт ответа.

4. Сервер наконец-то завершает генерацию HTML страницы и отдаёт её пользователю.

Вариант, описанный alexxale:

1. Пользователь обращается к PHP-скрипту.

2. Сервер генерирует HTML и сразу отдаёт его пользователю.

3. Пока пользователь скачивает страницу, сервер ображается к API соц. сетей.

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

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

Missing-male

> java-вовский JIT в сравнении это жалкое подобие левой руки

А вы видели результат работы JIT-компилятора? :)

Missing-male

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

Missing-male

Ну, и если уж быть совсем точным, на Scala переписали только высоконагруженные back-end, front-end так и остался на Ruby. Плюс, насколько я помню, в разных частях проекта используется ещё пара-тройка других языков.

Missing-male

> Дело в том, что PHP, благодаря наличию под него CMS-ок, очень часто позволяет вообще не писать, а ДОПИСЫВАТЬ и лазить по админке.

Для Python есть практически стандартизированный фреймворк Django. Админка в нём генерируется автоматически по описанию объектов базы данных, куча расширений позволяет сделать из него любую CMS-ку с пол пинка (при этом не притягивая кучу лишних фич), странички пишутся на чистом красивом языке, а изучается сам фреймворк за пол дня и 4 короткие страницы официального туториала. Так что, честно говоря, не вижу преимуществ PHP кроме того, что его все знают.

(А ещё документация врёт и shell_exec() возвращает ни разу не строку!!!11адинадин)

Missing-male

Время не замерял, но сдаётся мне, что достаточно быстро. Страницы (темплейты) в Django - это html + небольшие довольно простые вставки: Django не позволяет делать сложную логику прямо на странице, для этого есть серверный код. В Drupal, как я понимаю, генерация страницы происходит гораздо более сложным образом.

Сервер: боевой - Апач, для статических ресурсов можно тот же ngix (если, конечно, мне память не изменяет), во-время разработки достаточно встроенного сервера (т.е. начать работу можно сходу).

По ценам - сложнее, для Django они либо бесплатные для контрибуторов, либо относительно дорогие (ну либо ещё Google AppEngine, который ни рыба, ни мясо).

В то время, когда я занимался Django, для его запуска на Apache2 был нужен mod_python и mod_wsgi. Как с этим у хостеров - хз, практически не интересовался этим вопросом. По потреблению памяти - опять же, не обращал внимания, но на вид немного (по крайней мере явно меньше Java :))

То, где больше придётся кодить, зависит от типа проекта. Если это абсолютно шаблонный сайт, то Drupal, видимо, будет проще. Чем больше в проекте логики, тем выгоней становится использовать Django.

Вообще довольно хорошое сравнение можно почитать здесь: http://birdhouse.org/blog/2009/11/11/drupal-or-django/

> P.S. И кстати, dev.by работает на Друпале :)

Следствие его распространённости :) И, кстати, я бы не стал использовать для dev.by Drupal или какую-то другую распространённую CMS: сайт включает достаточно много фишек, и если в том же Django новые фишки добавляются за пару дней, то в больших CMS-ах требуется не только сделать фишку, но и придумать, как её встроить в существующую систему.

<< А ещё документация врёт и shell_exec() возвращает ни разу не строку!!!11адинадин >> чего?? :)

Где-то с месяц назад была весёлая история. Я пытался из PHP через shell_exec() вызвать джавовскую консольную программу, читающую один файл и генерирующую другой. Сама программа работает из шела на отлично. Но если делать то же самое из PHP-скрипта (по крайней мере из cronjob), программа обламывается где-то на середине, не генерируя выходного файла. После 2-х недель разбирательства, копания в документации, проб других аналогичных функций, обёрток и т.д. было решено переписать Java-утилиту так, чтобы она буквально после каждой строчки выводила на консоль то, что она сейчас делает, чтобы можно было отследить каждый шаг. PHP скрипт при этом выглядел примерно так:

$output = shell_exec("java -jar utility.jar");

echo $output;

Причём последняя строчка появилась имено на этом тесте, до этого всё, что печатала Java-утилита, выводилось в файл.

Согласно документации, shell_exec() выполняет программу и возвращает строку с выводом. Т.е. сначала выполняется программа, потом возвращается строка. Так говорит документация.

Однако на практике "строка" $output выводилась примерно так (в скобках вначале каждой строчки - примерное время в секундах с запуска скрипта, когда эта строчка была выведена на консоль):

[0] Starting program

[1] Doing stuff #1

[4] Doing stuff #2

[5] Finishing program

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

Отсюда следуют выводы:

* shell_exec() выполняется асинхронно;

* shell_exec() возвращает поток вывода, который при печати ведёт себя так же, как и строка.

В принципе, учитывая природу PHP, это довольно логично: если уж мы выполняем программу, значит мы хотим увидеть её результат и куда-нибудь его вывести, например, на страницу. Однако из-за недокументированности этой фичи можно нарваться как раз на тот сценарий, из-за которого мы и потеряли 2 недели:

- PHP скрипт вызывает shell_exec(), но не забирает и не распечатывает результат;

- shell_exec() создаёт соответсвующий процесс и байндит его потоки ввода/вывода;

- созданный процесс работает некоторое относительно большое время;

- PHP скрипт продолжает работать и в итоге завершается раньше, чем отработал дочерний процесс. Дочерний процесс автоматически убивается без ожидания завершения.

Вот из-за таких вот вещей я и предпочитаю как можно меньше взаимодействовать с PHP :)

Missing-male

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

Missing-male

Хотя, с другой стороны, возможно, что часть выводимых данных шла через stderr, а не через stdout, и каким-то образом обходила стек java-php-cron. Надо будет в понедельник проверить :)

P.S. Слушайте, откройте секрет, как искать в гугле исходники языков программирования? А то уже 4-й раз за месяц понадобилось, и каждый раз запрос типа "language sources" выдаёт кучу библиотек на языке language, но не сами исходники языка, а вы тут так сходу кинули ссылку. Или это уже просто известное место?

Missing-male

> Все взаимодействие модулей с Друпалом/другими модулями осуществляется с помощью хуков,

А, ну вот тут, видимо, и заключается основное отличие: Django, следуя общей идеологии Python, выносит все внутренности наружу. Т.е. вы не просто вешаете обработчики на заданный заранее каркас, а практически полностью пишете обработчики запросов. Фреймворк предоставляет только точку входа - мэппинг от запросов к функциям-обработчикам. Фукнции получают объект HTTP-запроса и должны возвращать HTTP-ответ. А внутри функции делайте что хотите: хотите вернуть просто текст - оборачиваете его в HttpResponse и возвращаете, хотите отобразить страницу - вызываете функцию render_to_response(template_path) и возвращаете результат, хотите прицепить свой собственный генератор страниц - то же самое, вызываете функцию генерации и возвращаете результат.

Это, кстати, та вещь, из-за которой мне не понравился Ruby on Rails - в Рельсах тоже пошли по пути, когда программист пишет только обработчики для хуков, а весь процесс отображения остаётся "магией". В итоге модификация процесса отображения превращается во что-то крайне нетривиальное.

Missing-male
+1

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

Немножко вопросов/критики (не ради уменьшения заслуг, а ради дальнейшего развития идеи):

1. Почему за основу взята программа российского вуза, пусть даже и одного из ведущих? Российская ИТ-индустрия всё-таки имеет свои отличия от белорусской, а сама по себе учебная программа всё-таки несколько проигрывает программам ведущих мировых вузов. Например, меня удивило наличие в списке специальностей ООП, но полное отсутствие декларативного программирования (сравните с курсом MIT 6.001, где подробно рассказывается про все возможные парадигмы - функциональное, процедурное, объектно-ориентированное, логическое ). Также удивило разделение на два курса алгоритмов и структур данных - всё-таки это очень близкие темы и обычно преподаются вместе. Удивило отсутствие курсов по сетям, математике, статистике или хотя бы теории вероятностей,

2. Также в программе есть несколько предметов, которые напрямую не относятся к разработке ПО, например, деловая переписка. В каком объёме будут преподаваться эти предметы? Не боитесь ли вы за счёт потери часов на них нанести вред образованию по центральным направлениям?

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

Missing-male
+3

Есть официальная программа, а есть то, что реально преподаётся в курсе. Например, в программе министерства образования может быть прописано что-то вроде "должен включать в себя основы создания программных систем в среде Интернет", а реально в курсе может рассказываться про PHP, Java, SaaS или вообще социальное взаимодействие через веб. Кроме того, я так полагаю, что сами курсы в программе тоже могут варьироваться и дополняться - не думаю, что в официальных документах прописаны такие вещи, как деловая переписка или коммандная работа. Так что всё не так и очевидно.

Missing-male
+6

Вероятней всего со следующего года несколько вузов всё-таки перейдут на систему 4 + 2, так что кое-какое движение всё-таки есть. Конечно, если опять не откатят :)

Missing-male

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

Missing-male

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

Missing-male
+2

Ужасный перевод (начиная с заголовка) посредственной статьи.

> замкнутые выражения

в оригинале: closures

правильный перевод: замыкания

> Хотя Python по-прежнему уступает по темпам разработки таким скриптовым аналогам, как Groovy и Jython, тем не менее [...]

в оригинале: Although it's been unable to regain momentum versus alternate scripting options like Groovy, Jython can be [...]

примерный перевод: хотя он [Jython] и не может сейчас соперничать с такими языками как Groovy, Jython всё ещё можно найти [...]

(в данном случае смысл получился вообще другой)

> В синтаксическом отношении он занимает промежуточное положение между Lisp и Scheme

в оригинале: syntactically, it sits between Common Lisp and Scheme.

Common Lisp, а не просто Lisp. Есть семейство языков Lisp, а есть конкретные диалекты, в т.ч. Common Lisp, Scheme и Clojure, который синтаксически занимает среднее положение между двумя предыдущими.

(для полноты картины: есть ещё LISP - самый первый диалект, придуманный Маккарти в 1958).

Дальше про Clojure просто чушь, как в переводе, так и в оригинале. Поддержка многопоточности никак не влияет на мутабельность и немутабельность данных. Конкретно Clojure ориентирован именно на JVM, реализация для CLR называется ClojureCLR, а для JavaScript/брауузера существует ответвление - ClojureScript, которое по очевидным причинам не может считаться полноценной реализацией. Ну и да, Clojure мультипарадигменный язык, в том числе прекрасно поддерживающий объектно-ориентированное программирование (причём сразу несколькими способами).

> Язык Scala часто называют «мультипарадигмальным»

> В сущности, это чистый объектно-ориентированный язык с функциональными возможностями.

Как _чисто_ объектно-ориентированный может быть мультипарадигменным? Тем более, что на самом деле Scala делает упор на функциональную часть, жёстко контролирую фичи ООП.

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

> Это еще один конструкт

нет такого слова, есть слово "конструкция"

Дальше расписывать лень, но косяков уйма.

Missing-male

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

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

Missing-male
+2

Игрался с Go ещё задолго до версии 1.0. Язык оставил самые лучшие впечатления. Во-первых, работает действительно быстро - нет задержек при старте, не нужно время для разогрева, да и общая скорость работы показалась выше, чем, например, у Java. В то же время, синтаксис на порядок приятней, чем в низкоуровневом Си (да и чем в Java, в приниципе тоже; я бы сказал, на уровне Scala), не нужно мучаться с ручной сборкой мусора, error-prone синтаксисом и т.д. Судя по описанию, как сборка мусора, так и потоки "стоят" гораздо меньше, чем в Java или C#. Есть встроенные в язык мэпы, замыкания, структуры и интерфейсы, но в то же время нет тяжёлых объектов, из-за которых Java и C# вляются такими "тяжёлыми". Самый близкий аналог из известных мне языков - Oberon 2, но Go всё же кажется более гибким, плюс лучше поддерживает многопоточность.

Missing-male
+2

В C# есть два типа объектов - value-type и reference-type. К первым относятся все приминтивные типы (int, char, bool, etc.) и структуры (struct). Ко вторым - классы, т.е. по сути все остальные объекты. Любой класс в C# наследуется от Object, а значит несёт в себе весь overhead этого объекта, а именно ссылку на сам класс, информацию для управления памятью и т.д. Хотя это и не прописано в стандарте, overhead составляет 8 байт. То есть в C# объект такого типа:

struct S {}

занимает 0 байт, а объект такого типа:

class C {}

целых 8 байт.

В принципе, в C# приветствуется использование value-types, а для простоты взаимодействия с системой классов даже придумали упаковку и распаковку объектов (boxing & unboxing), но количество объекто-экземляров класса всё равно остаётся очень большим, из-за чего серьёзно съедается память, а сборщик мусора вынужден работать ещё активней (следует отметить, что в Java ситуация ещё хуже).

В Go классов не существует (равно как и иерархии типов), существуют только структуры. Поэтому объект такого типа:

type S struct {}

будет занимать 0 байт*. За счёт этого программы получаются на порядок легче.

* - на самом деле конкретно пустой объект всё же может занимать какое-то минимальное место - 1, 4 или даже 8 байт, но это не будет являться реальными накладными расходами, а только лишь fix-ом для пустых объектов, точно так же, как в C++, где любой класс просто по стандарту обязан занимать >= 1 байта, чтобы адреса классов были разными. Если в классе/структуре появляется хоть один член (т.е. практически во всех реальных случаях), никаких fix-ов, естественно, не требуется.

Missing-male

Я полагаю, проекты, которые Google отдаёт на частичную разработку белорусским компаниям. Сколько таких компаний - не знаю, но пару раз такую информацию точно встречал.

Missing-male
+1

В Go есть интерфейсы, но эти интерфейсы нет необходимости объявлять при создании типа - тип автоматически удовлетворяет интерфейсу, если для него определены все объявленные в интерфейсе методы. Поэтому, чтобы получить функциональность, аналогичнную ToString() в C#, в Go достаточно сделать следующее:

type MyStruct struct { ... } // методы также могут быть определены и для примитивов: type MyInt int

func (st *MyStruct) String() string {

return "MyStruct(...)"

}

где `(st *MyStruct)` - это тип, для которого определён метод, и переменная-ссылка на экземпляр этого типа (аналогично this в C#).

`String()` - имя метода (в Go экспортируемые методы должны начинаться с большой буквы, локальные/приватные - с маленькой).

`string` - тип возвращаемого значения.

ну и дальше тело метода.

А какую роль void* вы имеете ввиду?

Missing-male
+1

По-моему, вы немного смешиваете понятия методов и интерфейсов. Методы обеспечивают полиморфизм с распределением по типу, так, что dog.Voice() вызовет лай, а cat.Voice() - мяуканье. Интерфейсы же гарантируют, что для некоторого типа в текущей области программы определены необходимые методы, например, гипотетический интерфейс FileLikeObject может требовать от типов, чтобы для них были определены методы read(), close() и reset() - любой объект с такими функциями будет автоматически удовлетворять интерфейсу (обратите внимание на аналогию с утиной типизацией в Python и известной концепцией file-like объектов). Но и методы могут существовать без интерфейсов, и интерфейсы без методов.

Так вот. Mixin-ами будут являться именно методы, но не интерфейсы. Так глубоко не нырял, но насколько я понимаю, методы ищутся в соответствии с областями видимости, и первой областью видимости является текущий модуль. Соответственно, если вам не нравится реализация метода ToString() для объекта SomeStruct из модуля A, то в своём модуле B вы можете определить новый метод `(st *SomeStruct) ToString()`, и при компиляции все вызовы внутри вашего модуля будут ссылаться на вашу же реализацию. (В деталях могу ошибаться, но общую идею, думаю, вы поняли).

> С неявной реализацией - интересно, это компилятор проверят? Выходит если у разных интерфейсов есть одинаковый метод, я его не смогу реализивать по-разному для разных интерфейсов?

Да, компилятор. Нет, не сможете. Так же, как и в Java или C# вы не можете имлементить два интерфейса с одинаковым методом, но с разной реализацией.

Касательно void* - в Go есть нечто похожее в виде пустого интерфейса (interface{}), но правила преобразования там немного другие. Если интересно, можете посмотреть, как в Go реализована сериализация/десериализация в JSON.

Missing-male
+1

Ну, учитывая, что Go идеологически ближе к C, чем к C#, то скорее всего нет - пакеты (модули) не являются объектами первого класса, и вряд ли над ними можно совершать большое количество операций.

Missing-male
+1

А я то думаю, чего это у меня карма в верху экрана скачет. Два минуса и ни одного комментария за ответ на технический вопрос - в лучших традициях dev.by :)

Missing-male
+1

Ахаха, пузатые объекты объеденяются и атакуют! Мне же теперь кошмары по ночам сниться будут! :)

Missing-male

Хех, напросился на плюсики :) Спасибо.

Missing-male
+3

Подход, конечно, странный, но хоть узнал, что к чему, а то так бы и мучался любопытством ;)

1. Вам показалось. Я ответил на конкретный вопрос про "тяжёлые" объекты в C#, рассмотрел вопрос ровно с той точки зрения, с которой происходило сравнение. Ни с какой другой точки зрения в этом ответе языки я не сравнивал.

2. Нет, не правильно: в Go есть процедура new(), позволяющая размещать структуры на хипе. Не знаю, почему вы так подумали, ведь тот же C тоже не имеет классов, но работать с хипом вполне себе умеет.

3. А вы с чем-то не согласны? Вот вам вырезка из FAQ Сатруструпа для создателей компиляторов C++: http://www2.research.att.com/~bs/bs_faq2.html#sizeof-empty . Это, конечно, не совсем стандарт, но учитывая, что речь шла о какой-то возможной детали реализации языка Go, такие мелочи не играют роли.

А у меня, как бе, и не было цели создавать полноценный обзор этого языка, однако я полагаю, что впечатления человека, уже что-то делавшего на Go, могут оказаться более полезными, чем перевод абстрактной статьи из интернетов. Если язык заинтересовал, в сети можно найти всё, что нужно, чтобы самостоятельно оценить все его плюсы и минусы.

Missing-male

1. На самом деле тут много факторов. Основная проблема состоит в том, что в чисто объектно-ориентированных языках вам _приходится_ создавать объекты на куче. Что в Java, что в C# по сути нет таких понятий как модули и функции. Есть статические методы, но они значительно ограничевают саму по себе объектно-ориентированную парадигму (в частности, они не могут реализовывать методы интерфейсов), поэтому многие разработчики справедливо решают отказаться от них. В то же время, такие языки как C/C++ и Go, поощрающие обычные функции и объекты, размещённые на стеке, могут реализовать ту же функциональность средствами гораздо меньших затрат памяти на хипе. Для примера, возьмём 2 программы для доступа к базе данных - одну на C# и одну на Go:

C#: http://csharp.net-informations.com/data-providers/csharp-sqlcommand-executereader.htm

Go: http://code.google.com/p/mysql-connector-go/

В C# для доступа к данным необходимо создать объекты SqlConnection, SqlCommand и SqlDataReader. Эти объекты создаются при каждом вызове, и при каждом вызове места в хипе уменьшается на соответствующее количество байт, приближая тем самым сборку мусора. Создание объектов с коротким сроком жизни настолько распространено в чисто ОО-языках, что инженеры Sun даже придумали для этого явления специальное название - "высокая детская смертность" (умеют они выбирать имена: в сборщике мусора JVM также есть такие понятия, как "эдэм" и "зоны выживших"). Кстати говоря, согласно той же сановской документации именно большое количество короткоживущих объектов стало причиной разделения памяти на поколения.

Теперь посмотрим на код Go. Там для осуществления запроса к БД нужно создать... 0 объектов. Т.е. хип вообще не задействуется, а немногочисленные структуры создаются на стеке и автоматически уничтожаются при выходе их функции.

Так вот, возвращаясь к нашим баранам, а вернее к оверхеду в 8 байт. При таком широком использовании объектов на хипе накладные расходы в виде 8 байт начинают играть играть значительную роль. Ситуация усугубляется тем, что многие объекты практически не несут собственных данных, а только этот оверхед. Всякие Reader-ы, Stream-ы, Iterator-ы и т.д. могут содержать только какой-нибудь индекс, указывающий на прогресс считывания данных. Один индекс, 4 байта, к которым прибавляется 8 байт оверхеда. Всё это в сумме даёт такую неплохую нагрузку на хип по сравнению с такими языками, как Go.

Справедливости ради надо заметить, что в C#, увидев проблемы Java, приняли ряд мер и несколько улучшили ситуацию, введя boxing/unboxing и ряд оптимизаций на уровне компилятора/рантайма. Однако при проектировании большой системы всё-таки следует помнить, чего стоит активное порождение объектов сборщику мусора.

2. В компилируемых статически типизированных языках нет необходимости хранить информацию о типе во время выполнения программы. Все адреса, известны, все операции определены заранее, все функции слинкованы. Ссылка на тип в ОО-языках нужна в первую очередь для хранения таблицы виртуальных методов. В Java, например, тип объектов-дженериков в рантайме не сохраняется (правда сделано это больше для обратной бинарной совместимости, чем в качестве фичи, но как proof-of-concept сойдёт). В Go нет иерархии наследования, а все методы линкуются статически, поэтому нет никакой необходимости хранить ссылку на тип. Сборщик мусора, судя по всему, сам отслеживает размеры объектов. Из 8 байт оверхеда остаются только биты синхронизации, но Go использует модель экторов, так что блокирующие локи тоже можно спокойно вынести во вне объекта.

3. Нет, господь с вами, выравнивание типов - это вещь не сильно "тяжёлая", но очень полезная, так что искренне надеюсь, что в Go она тоже используется :)

Missing-male
+2

Если дошёл до потолка, ищи бизнес-партнёра и начинай своё дело - либо превзойдёшь потолок, либо поймёшь, что ещё не так и крут.

Missing-male

> Если ваше утверждение верно, можно работать супер медленно и неэффективно, и вам все ровно

> будут продолжать платить. При этом проект никогда не закончится и заказчик его никогда не получит :)

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

Missing-male
+1

Fixed price, кстати, тоже ещё не означает, что заказчик уже определился с бюджетом и хочет найти человека, который сможет сделать работу за эти деньги. Fixed price означает только то, что вы не получите ни больше, ни меньше этой суммы, независимо от того, будете работать по 1 или по 20 часов в день. С одной стороны это гарант для заказчика, что ему не придётся заплатить вам больше, чем он расчитывал, с другой - мотиватор для вас сделать это как можно быстрее - всё равно за пару лишних часов прокрастинации вам никто не заплатит.

Missing-male
-1

То есть логика снова не в моде, а истинность утверждения теперь определяется длиной письки послужного списка? 150 проектов. Сможете проверить? Нет? Тогда зачем спрашиваете?

Missing-male

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

Во-вторых, я вам прозрачно намекнул, что при почасовой оплате заказчик вполне себе может контролировать ход выполнения работы. Если человек за неделю ничего не сделал или сделал слишком мало, то заказчик может просто расторгнуть контракт и найти другого исполнителя, оставив этому негативный отзыв. Принципиальных проблем здесь нет. С другой стороны, при подходе "у меня есть столько-то денег, сделаешь ли ты за них такую-то работу" есть куча ситуаций, когда заказчик останется либо в сильном проигрыше, либо просто не найдёт исполнителя. Вы приходите к дизайнеру и говорите: "у меня есть 100 баксов, сделай мне дизайн". Дизайнер считает, что это займёт у него около 10 часов, по ставке 10 баксов в час получается как раз $100, поэтому он соглашается. Через 10 часов вы получаете дизайн, который _вам_ не нравится. И тут либо вы в проигрыше, потому что дизайн не тот, либо дизайнер, потому что ему придётся подстраиваться под ваши заморочки и в итоге потратить гораздо больше своего времени за те же деньги. Корректно из этой ситуции можно выйти только при почасовой оплате, хотя бы на этапе создания и утверждения скетчей - тогда вы будете спокойны, что получите то, что хотите, а дизайнер - что его рабочие часы будут адекватно оплачены.

Missing-male

1) если вы готовы платить за все три прототипа (и за все повторения пункта 1) - ради бога, но чем тогда это лучше почасовой оплаты? Или вы хотите заплатить за 1, а получить 3? Боюсь, что в этом случае вас просто пошлют.

3) "примерно в таком духе" - это смертельная фраза не только для дизайнеров, но и для программистов ;) "Примерно в таком духе" означает, что клиенту просто нравится сайт конкурентов, но о том, каким он хочет видеть _свой_ сайт, он не имеет понятия.

4) честно говоря, если бы клиент, не шарящий в моей области, кинул бы мне ссылку для "дообучения", я бы его послал куда подальше. Исключение: заказчик кидает ссылку на новые тренды просто ради информирования о том, о чём я, возможно, ещё не слышал. Но это именно информирование, решение, что применять, всё равно должно оставаться за мной.

Missing-male

Ой, не туда запостил. Ну вы поняли.

Missing-male

Таки логотипы - это немного другое. Логотип можно долго доводить до ума, но основную идею можно реализовать довольно быстро - главное, чтобы идеи были. С дизайном сайта всё сложней: во-первых, это вайфреймы, во-вторых, цветовая гамма, в-третьих, картинки, в-четвёртых, шрифты и т.д. И всё это нужно согласовать - как между собой, так и с заказчиком. Дизайн страницы сайта, как правило, стоит в несколько раз дороже логотипа. Причём это одной страницы, а чтобы получить чёткое впечатление нужно хотя бы 2 - главную и внутреннюю. А всё это занимает время и, соответственно, стоит денег.

Missing-male

Пардон, но дизайнеру, который ни разу не был на сайте Лебедева, я бы работу не доверил. Не потому что Лебедева люблю, а тупо из-за отсутствия минимального кругозора. А если такой кругозор есть, то я лучше постою в сторонке и посмотрю, как человек делает то, в чём разбирается лучше меня.

> Если Вы считаете, что Лебедев никогда ничего путного не писал

Особенно информативено его твиттер, ага :)

https://twitter.com/temalebedev

> Мне хотелось сделать очень интересным свой сайт

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

> Заказчик платит свои деньги, если Вы не так известны, как Лебедев - можно Вам что-то и сказать, свое видение, по моему.

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

Это напоминает Фрейда, который считал, что пациенты должны платить деньги. Много денег. Иначе пацианты считают, что терапия бесполезна (полезная вещь не может стоить дёшево!), и весь эффект пропадает. То же самое и с Лебедевым: пока его студия держит статус лидера, заказчики будут оставаться довольны, даже если получат на самом деле отвратный дизайн.

Missing-male
+2

В данном контексте забавно смотрится новость:

"Некоторые индийские фирмы рассматривают Беларусь как территорию аутсорсинга для своих разработок, которые в дальнейшем они собираются продавать в Европу... В будущем мы также ожидаем увеличения числа ИТ-подразделений индийских компаний в Беларуси", - сказал посол.

Missing-male

Что-то вы тут намешали всего. MapReduce - это одна конкретная вычислительная модель, придуманная в Google для работы с обратным индексом. Естественно, это не было первой работой по параллельным вычислениям, но получившаяся модель (фазы вычислений, использование key-value пар) оказалась настолько удобной, что модель получила широкое распространение.

При чём тут Java, я тоже не понял. Вроде речь шла о гуглевской реализации модели, которая, насколько я помню из их презентаций, написана на C++. На Java написан Hadoop. Но ни гугловская реализации, ни Hadoop не являются продуктами, которые можно продать и, соостветственно, которые нужно рекламировать.

Missing-male

Это ответ на ваш предыдущий комментарий в треде, конечно же.

Missing-male
+1

Ещё раз. MapReduce - это одна из возможных моделей. Так же, как, например, QuickSort - это только один из алгоритмов сортировки. Естественно, из тех же или подобных кусочков можно создать и другие модели параллельной обработки данных, так же, как можно создать другие алгоритмы сортировки. Естественно, мир моделей не заканчивается на параллельной обработке данных, так же, как мир алгоритмов не заканчивается на алгоритмах сортировки. Но есть конкретная схема - MapReduce - которая заработала популярность. Говорить о каком-то маркетинговом заговоре на основании популярности модели - это как-то глупо.

> "Google реализовал MapReduce на C++ с интерфейсами на языках Python и Java".

Либо я чего-то не знаю, либо вы опять говорите какую-то ерундну. Насколько мне известно, гуглевская реализация используется исключительно внутри самой корпорации. Ну, максимум в их сервисах типа GAE. В виде библиотеки, бесплатной или платной, гуглевский фреймворк нигде не распространяется и не используется. И если вы не работаете в Google, то доступа к этому фреймворку у вас не будет.

Missing-male

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

И ещё раз. Быстрая сортировка - это тоже идея с "урезанным списком возможностей", ведь она не позволяет делать много вещей, которые позволяют сделать алгоритмы вообще. Так что, теперь не пользоваться ей или что? "Дутая популярность"? Да кем она дутая? Это ведь не новый iPhone, который надо рекламировать и внушать людям, что это что-то крутое, чтобы продать побольше устройств. Google разработал модель, которая хорошо помогла им в собственной работе, и рассказал об этом остальным - на научных конференциях, на митапах инженеров. И с этого они не получают ни бакса - они не продают свой фреймворк, они не судятся по поводу патентов на MapReduce. Они просто создали модель и поделились ею с сообществом. Если вам это не нужно - ради бога, вас никто не заставляет.

> Про маркетинг я упоминал в контексте - почему не плодятся сотнями аналоги фреймворка от Google. - Нет смысла.

Скажите это разработчикам Hadoop, HDFS, и т.д., а также директорам Yahoo! и десятка других компаний, использующих эти фреймворки.

> 1) Вы сказали, что MapReduce от Google не имеет отношения к Java.

Вы сказали про решения, доступные для Java программистов. Решение от Google не доступно для большинства Java-программистов. Написано это решение тоже не на Java. А интерфейсы к библиотеке можно написать практически для любого языка программирования, Java здесь никак не выделяется. Так каким образом параллельные вычисления на Java связаны с гуглевской реализацией MapReduce?

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

Опять же, причём тут другие реализации? Вы говорили конкретно про гуглевскую реализацию, и про то, какой гугль засранец, что навязал всем свой MapReduce. А тут уже речь пошла о каких-то других реализациях. Если вся вина гугля в том, что они рассказали про то, что используют в компании и за счёт чего добиваются хороших результатов, то ладно, с этим обвинением я согласен. Но как-то я на них за это не в обиде.

Missing-male

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

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

Вопрос в тему: как с помощью ручного управления памятью и/или RAII организовать эффективную работу с общими для десятка потоков ресурсами?

Missing-male

Я вам указал на конкретные недостатки вашей аргументации, вне зависимости от контекста. Меня мало интересует парное программирование, но если уж вы критикуете чью-то работу, делайте это обосновано. Я тоже не считаю MapReduce гениальной идеей, но я отдаю должное инженерам, которые смогли формализовать, а затем и реализовать её. Вы же начали рассуждать на тему, какое это урезанное решение, какой всё это фарс, а на самом деле "король голый". Именно на это я и ответил. Плюс указал на бессмысленность логических переходов, в частности, на упоминание Java, которая к самой модели MapReduce (и, кстати, к вопросу креативности людей при парном программировании, раз уж вспомнили) никакого отношения не имеет.

> Вы сравниваете разные алгоритмы сортировки, в едином для них контексте алгоритмов и едином для них [...]

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

> Скажите это на опеннете. Там раза 2 в месяц появляются тесты производительности на этот счет. По разным таким кластерным решениям, реализованным на Java и/или на С++.

Перечитайте свою фразу - речь шла о том, что "не плодятся сотнями аналоги фреймворка от Google". Сотнями действительно не плодяться, но лишь потому, что уже есть опенсорсный Hadoop, и вот его используют очень многие, в том числе весьма именитые компании. Спорить же о производительности абстрактных программ на абстрактных задач не имею никакого желания.

> Единственная тема для расхождения у Вас и у меня была в этом, реальная, что Вы сказали, что смотрели презентацию от Google и в ней упоминался только С++, про Java речи не было. Говорили такое? Говорили. Я привел ссылку из Википедии, что API для Java есть. Вопрос закрыт.

Мой вопрос состоял в том, каким боком вы привязали Java к гуглевской реализации MapReduce. В частности, меня удивила фраза:

> Да, конечно, реализовать имплементацию данного алгоритма под Java - это тоже большое дело.

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

Missing-male

С некоторыми вещами не соглашусь. Сборщик мусора - это не просто упрощение работы с памятью и автоматический контроль за вызовом delete. Это другая модель управления памятью. В некоторых случаях она ведёт себя лучше, в некоторых - хуже.

Например, в C++ вы можете размещать объекты на стеке. Это даёт максимально возможную скорость уборки использованной памяти - вы просто изменяете значение указателя на вершину стека и всё. Пара машинных команд. Однако, много больших объектов на стек вы не положите - придётся пихать что-нибудь в память. Для размещённых в памяти объектов C++ по умолчанию использует delete для удаления использованных объектов. При этом удаление, как правило, также является дешёвой операцией - менеджер памяти всего лишь помечает кусок памяти как свободный. Однако выделение памяти становится гораздо более дорогой операцией - менеджеру приходится искать подходящий для объекта кусок памяти, при этом стараясь сделать это максимально компактно, чтобы избежать фрагментации. Кроме того, когда речь заходит о многопоточных программах, ручное управление памятью становится той ещё занозой в пятой точке, ибо становится сложно определить, когда объект больше не используется ни одним из потоков. Тогда на помощь приходят всякие ухищрения типа подсчёта ссылок, что, по сути, уже является автоматической сборкой мусора. Работает всё это вполне неплохо, однако становится сложно предсказать, как именно программист решит управлять своими ресурсами, следовательно, становится сложней написать эффективный менеджер памяти, а решения типа shared_ptr всегда будут неполны по своей функциональности. В этом случае имеет смысл подойти к проблеме с другой стороны - забить на поведение программиста, отобрав у него возможность вручную удалять память. Общая картина использования памяти в этом случае станвится проще, а значит появляется возможность эффективно решить её для большого количества возможных программ. Вот тут и появляются GCs а-ля джавовских. Т.е. GC действительно может быть эффективней других стратегий управления памятью, но только в определённых условиях. И это справедливо для любой стратегии.

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

Missing-male

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

Hadoop - это фреймворк. Готовая система кроме фреймворка состоит из множества другого кода, который не зависит от фреймворка. И уж тем более от него не зависят задачи. А не зная задач и деталей реализации (кроме того, что там используется такой-то фреймворк), речь можно вести только о каких-то абстрактных материях.

> Мои слова про мейнстрим в программировании на кластерах - Вы опустили, не прокомментировав.

Какие именно?

> У Вас, извините, не хочу обидеть - меньше знаний, поэтому Вы защищаете Гугл.

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

Missing-male

Не, так единственный однозначный и не зависящий от задачи недостаток GC в Java, о котором я говорил, - это размещение объектов в памяти, а не на стеке. Если объект всё-таки размещается в памяти, то ещё большой вопрос, что эффективней - GC или ручная сборка.

Missing-male

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

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

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

Вы мне предлагаете тянуть в любое многопоточное приложения системы для распределённой обработки информации?

> Вы не знаете мейнстрим-технологии, используемые при программировании на кластерах. Это факт.

Мне совершенно не хочется с вами спорить о том, что считать мейнстримом, поэтому я просто выскажу свою точку зрения, а вы уже воспринимайте её как хотите.

Увеличивать производительность можно двумя способами - за счёт вертикального и горизонтального масштабирования. CUDA, С++ и все супербыстрые технологии относятся к вертикальному масштабированию. Сюда же можно отнести ПЛИС и прочие оптимизации на уровне железа. Вертикальное масштабирование исторически появилось раньше и до сих пор активно используется. Горизантальное же масштабирование делает упор на количество одновременно работающих машин. Google, Yahoo! и многие прочие решили, что вместо 10 дорогих машин с CUDA и прочими примочками лучше купить за те же деньги 20 дешёвых машин - мало что по производительности получившийся кластер не будет уступать кластеру из дорогих машин, так ещё и при поломке их можно будет дёшево заменить.

Что же касается фреймворков, стандартов и вычислительных моделей, то в мире существует огромное их количество. Распределённые базы данных, поисковые движки и т.д. - все они используют свои собственные наработки для распараллеливания вычислений. Если для вас стандартом является MPI/OpenMP - ради бога, пользуйтесь на здоровье. Меня же устраивают собственные мозги, помогающие мне проектировать распределённые системы с оптимизацияим, доступными только в моей конкретной системе.

> Уже 5 раз написано, что Java API для MapReduce есть, Вам даже цитату из Википедии предоставили. А Вы заявляли обратное.

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

Missing-male

keil>> Вы мне предлагаете тянуть в любое многопоточное приложения системы для распределённой обработки информации?

> "MPI применяется для систем с распределенной памятью. Для систем с общей памятью применяют OpenMP."

Это я так намекнул, что многопоточные приложения не ограничиваются распределёнными системами - существует широкий пласт (вероятно, гораздо шире, чем для распределённых систем) многопоточных программ, предназначенных для работы на одной машине. И при ручном управлении памятью в таких программах начинается адский ад. Во-первых, это чертовски error-prone, во-вторых, вариантов ручного управления настолько много, что становится сложно предсказать, какая архитектура менеджера памяти будет оптимальной. Автоматическая сборка мусора а-ля Java GC (в отличие от решений типа shared_ptr) предоставляет хорошую альтернативу. Если углубиться дальше, то из Сановских/Оракловских доков по сборщикам мусора можно увидеть тенденцию создания в программах большого количества короткоживущих объектов в памяти ("высокая детская смертность"). В этом случае выделение памяти для такого большого количества разовых объектов (т.е. C++ way) оказывается более дорогим, чем копирование нескольких оставшихся в живых объектов и быстрая зачистка освободившейся памяти (Java way). Конечно, это не делает GC более быстрой технологией для любых программ, и для большинства своих программ при возможности я всё ещё предпочитаю использовать RAII, однако говорить об однозначном преимуществе по скорости ручного управления памятью без огладки на задачу и environment тоже не приходится.

> (графические и математические ускорители - опционально)

Я вам про Фому, вы мне про Ерёму. Я сказал, что использование спец железа на практике часто оказывается нерентабельным (пруф - архитектура кластеров Yahoo!, могу ещё поискать видео с гуглевского Tech Talk в Москве, так вроде об этом говорили). С тем, что MPI/OpenMP можно использовать для горизантального масштабирования я не спорил.

> Вы не можете сказать однозначно - на сколько они используют или не используют MPI + OpenPM. Потому что тот же MapReduce от Google может активно использовать эти две технологии. Вы исходники смотрели MapReduce? Нет, не смотрели. Вы смотрели исходники гугловских С++-бакендных движков? Вероятнее всего нет.

Вы опять смешиваете кучу понятий из разных категорий, поясняйте, что именно вы имеете ввиду. Используют ли поисковые движки и распределённые БД библиотеки для MPI/OpenMP? Я довольно глубоко копался в Solr, в том числе в последней, распределённой версии, и могу вас заверить, что нет, не используют. Использует ли Solr соответсвующие протоколы? Тоже нет. Распределённые базы данных? MongoDB сойдёт? Кластерная архитектура в Монго строится на нескольких типах узлов и специфическом взаимодействии между ними, никаких концепций из MPI я там как-то не замечал. Зато MapReduce они эксплуатируют по полной (кстати, давно хотел спросить - почему вы всё время противопоставляет MapReduce и MPI, если первое - это алгоритм/модель вычислений, а второе - набор протоколов?). Собственно, задачи поиска, добавления и т.д. данных строятся именно на модели MapReduce. Какие-то специфические библиотеки для MPI они, может быть, и используют, но архитектура этого не требует, да и упоминаний про MPI в их доках я ни разу не видел.

> 2) Использовать MPI + OpenPM или их аналоги. Решение переносимо по определению. Потому что, например, и для Windows, и для Linux, и для Solaris - есть имплементации этих технологий. Но Вы пишите ЕДИНЫЙ КОД. Который подойдет для всех (!) этих платформ.

boost. Или С++11, где тот же boost "встроен". И будет вам счастье. Для других языков такой проблемы, как правило, изначально не стоит.

> Понимаете, дело еще в том, что такие фирмы как Sun, Oracle, Microsoft - имеют готовые решения для развертывания HPC-платформ и API для программирования на этих кластерах. И их эти API - базируются на MPI или OpenPM, или комбинации их. Доступны решения и от Intel.

Не уловил вашу мысль. Ну существуют, круто. А что именно вы этим хотите доказать?

> Ваше право - выбрать п.1 или п.2. Никто никого не неволит. Но под 95% серьезных математических, физических, химических задач в мире, требующих вычислений на кластерах и суперкомпьютерах - используют MPI + OpenPM.

Давайте пруфы. Вот конкретно с этой цифрой - 95%, или по крайней мере близкой к ней. А заодно статистику по проценту "серьезных математических, физических, химических задач" от общего количества задач, выполняемых на кластерах.

По поводу "реализовать имплементацию данного алгоритма под Java - это тоже большое дело" вы мне что-нибудь ответите?

Missing-male

> Ну вот первое нагугленное.... про эффективность:

Не, ну честное слово, мне уже надоело отвечать на замечания про отдельные бенчмарки на сферических задачах в вакууме. Я могу вам за пару часов написать программу, которая на этой конкретной задаче порвёт и Hadoop, и HPCC на британский флаг. Будет ли моя программа лучше, чем эти системы? Нет. Она просто будет заточена под эту задачу. Говорить, что одна система лучше другой на основании одной задачи и без учёта архитектуры этих систем - абсолютно пустая затея. И после этого вы говорите, что моя аргументация "не спортивна"?

> А если миллионы леммингов бегут к обрыву, так это просто так модно на данный момент

Действительно, Facebook, Yahoo!, Amazon и дальше по списку - абсолютные лемминги, не разбирающиеся в технологиях и готовые пожертвовать своим бизнесом, лишь бы бездумно пойти за большинством.

> Далее, те самые высокопроизводительные вычисления далеко не ограничиваются моделью Map-Reduce.

С этим я и не спорил.

> Зачем же вы мои общие рассуждения сужаете на некоторый класс алгоритмов

Ваши общие рассуждения звучат как нечто однозначное и справедливое для любых высоконагруженных систем. Я всего лишь привёл пример, когда это не так.

> Не понял при чем тут ручное управление памятью к обеспечению бесконфликтного доступа к ресурсам из нескольких потоков. Особенно в контексте нашего разговора - как тут поможет сборщик мусора?!

http://dev.by/blog/64632#comment-44372

Missing-male

> "Для систем с общей памятью" и далее - " применяют OpenMP.".

"применяют OpenMP" - этой фразой вы хотите сказать, что _некоторые_ программисты для многопоточности в C++ на одной машине применяют OpenMP или что _все_ программисты высоконагруженных систем для многопоточности используют OpenMP? С первым я и не спорил, второе - откровенный бред. Поясните, пожалуйста, какой из вариантов вы имеете ввиду, ибо я из ваших слов улавливаю второй вариант.

> Далее у вас идет добавление в контекст обсуждения все новых и новых тем (GC, рентабельность различных конфигураций железа), ладно отвечу:

Тема GC возникла из разговора с testuser, я не просил на неё отвечать.

Рентабельность вылезла из обсуждения кластеров Google & co., мой основной тезис был в том, что использование CUDA и прочих железячных решений является не единственным и не всегда лучшим способом увеличения производительности, есть и другие пути.

> По поводу GC. MPI _никак_ не завязан на смешение его с GC используемым для вашего кода.

В дополнение к уже сказаномму по поводу GC. Зачем мне использовать MPI в той же Java в пределах одной машины, если все средства управления памятью уже есть и вы по-умолчанию пишете единый для всех платформ код? Какие преимущества мне даст MPI в этой ситуации?

> Рентабельность тут никоим образом не примешана. Вы можете использовать MPI+OpenMP - для высокорентабельных, для низкорентабельных, БЕЗ РАЗНИЦЫ.

Я где-нибудь с этим спорил? Вы опять видите Ерёму, но не видите Фому: этот ответ касался конкретно использования CUDA. Я вам даже специально в конце абзаца написал: " С тем, что MPI/OpenMP можно использовать для горизантального масштабирования я не спорил".

> А что там используется для многопоточности? Раз Вы "глубоко копались", то должны знать. Тем более раз отвергаете использование там MPI+OpenMP.

Для многопоточности там используются потоки и мониторы. Вы, вероятно, хотели спросить, что там используется для построения устойчивого кластера. Для поддержания общей конфигурации (состояния кластера) там используется ZooKeeper, для репликации до недавнего времени использовались встроенные средства Unix, сейчас переписали на чистую Java - смотрите replicationhandle.

> Я выше писал, что сам MapReduce может использовать MPI+OpenMP.

Может, но, судя по всему, не использует. Если не верите - исходники Монги полностью открыты, как найдёте там MPI/OpenMP для MapReduce - скажите, с удовольствием посмотрю на имплементацию.

> Как один из вариантов работы с многопоточностью - конечно. Только Вы не знаете возможностей связки технологий MPI+OpenMP. Соответственно не можете сравнить.

Я не пытаюсь их сравнивать, я пытаюсь показать, что на MPI/OpenMP свет клином не сошёлся, что есть другие способы делать то же самое, им много и они активно используются. Обратите внимание: я не пытаюсь сказать, что MPI/OpenMP не следует применять, я говорю именно о том, что это всего лишь один из возможных способов решения проблем.

>> Ну существуют, круто. А что именно вы этим хотите доказать?

> Серьезные ребята из серьезных компаний, для HPC (высокопроизводительных вычислений) создали инструменты, библиотеки и трансляторы, позволяющие использовать MPI и/или OpenMP. Под выпускаемые ими хардварные или серверных платформы, позиционируемые для HPC.

Ёлки-палки, как с вами сложно. Это был вопрос. Я понимаю, что существуют такие решения. Но к чему вы сказали эту фразу? Вы же, наверное, не просто так её сказали, а хотели что-то доказать. Так вот, что вы хотели доказать то?

> Не уверен, что существует точная цифра в принципе. [...] Я привел свои личные оценки

Вы, когда приводите личные оценки, поясняйте, что это именно _ваши личные оценки_.

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

> Дык уже отвечал, и не раз. Есть Java API? - Есть.Затратили они некоторые усилия? - Затратили. [...] Правильно я сказал, что "реализовать имплементацию данного алгоритма под Java - это тоже большое дело"? - Конечно же да. :)

Каким боком имплементация _алгоритма_ относится к написанию _обёртки_ к библиотеке? Вы пытаетесь оправдаться, и у вас это совершенно не получается.

Missing-male

В который раз поражаюсь вашей любви к железячным ускорителям и игнорированию других решений - про GPU вспомнили, а то, что можно купить кластер на Амазоне и сделать то же самое как-то не упомянули. А между тем, основная проблема с кражей поролей - это дыры в сайтах, которые позволяют слить саму базу паролей: подобрать пароль по имеющимуся хешу - задача тривиальная (тем более, если вместе с базой злоумышленник слил и code base проекта вместе с константой для соли), а вот получить доступ к этой базе в системе с грамотно построенной безопасностью гораздо сложней. Естественно, перебирать онлайн - тоже не comme il faut: там и каптча, и отслеживание по ip, а обойти эти вещи может уже гораздо меньший процент крекеров.

Missing-male

Промахнуся ответом, смотрите ниже.

Missing-male

1. Для взлома паролей, из-за которого вы вспомнили GPU, совершенно нет разницы, где расположены сервера. Только за покупку железа вам сразу придёся выложить кучу денег, а облако вы можете заказывать по необходимости.

2. Ну, специфика отличается, алгоритмы другие - это понятно. А посыл то у вашего комментария какой?

3. Пруф? Таблицы производительности, условия сравнения?

Впрочем, спорить с вами я не собираюсь - интересных фактов для обсуждения у вас как всегда нет, а доказывать вам что-то я не имею никакого желания. Две основные мысли, которые я хотел донести: 1) за последние годы выросли вычислительные мощности вообще, а не только в GPU; 2) взломать слитый хеш можно так или иначе, поэтому в первую очередь нужно думать о том, как вообще не позволить злоумышленнику получить этот хеш.

Missing-male

А теперь прочитайте только то, что я написал, а не то, что вы додумали. В п. 1 я не говорил про облака с GPU (BTW, на некоторых хостингах его устанавливают по требованию), я сравнивал аренду серверов в облаке и покупку железа к себе в квартиру (работу, склад). Один минимально приличный сервер с GPU будет стоить не меньше $1000; в облаке на эти деньги можно спокойно арендавать на месяц 20 машин, и ещё останется. Вы уверены, что один GPU порвёт по скорости 20 машин в облаке? Я - нет. Соответственно, в п. 3 я спрашивал не про сравнение CPU c GPU на некоторых задачах, я спрашивал про сравнение кластера компьютеров (без GPU) и сервера с GPU. Вы ведь сказали, что именно они сейчас позволяют _максимально увеличить производительность_. Ну так вот, покажите хотя бы одно сравнение, где было бы сказано, что GPU одназначно рвёт любые другие техники перебора паролей.

Вы раз за разом кидаетесь необоснованными суждениями, а когда вас просят привести факты, начинаете огрызаться и называть всех идиотами, не разбирающимися в теме. Считаете себя самым умным - ради бога. Я комментарии пишу не для вас, а для сохранения баланса - чтобы мнение одного человека не начинало восприниматься как объективная истина.

Missing-male

Как я уже сказал выше - вы Д'Артаньян, я говно. Если вместо аргументированного спора вы можете только называть собеседника идиотом и отсылать в википедию (которая, как бе, никак не противоречит словам оппонента), то это ваше дело. Конструктивного диалога я тут не вижу, каких-то новых знаний от вас я тоже не получаю, так что можете спокойно оставаться при своём мнении, мне от этого не будет ни жарко, ни холодно.

Missing-male

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

я: утверждение Б неверно

вы: неправда, утверждение А верно!

я: я и не спорю, утверждение А действительно верно, но я говорю про утверждение В

вы: да вот вам книга, где написано, что А верно!

я: ёпрст, но я же говорю про утверждение Б!

вы: вы не понимаете базовых вещей об А, до свидания!

Утверждение А - это то, что 1 GPU на специфических для него задачах рвёт 1 CPU. Утверждение Б - что для специфических задачах GPU рвёт по всем параметрам CPU, вне зависимости от количества первых и вторых.

Теперь берём гипотетическую ситуацию: к нам в руки попала база хешированных паролей с LinkedIn, один сервер с GPU и все вычислительные кластеры Google. На чём мы быстрее сможем взломать пароли - на одном сервере с GPU или на всех кластерах Google? Надеюсь, что хотя бы в ответе на этот вопрос мы с вами сойдёмся, и вы ответите, что на кластере Google.

Ок, значит какое-то количество CPU всё-таки может перевесить один GPU даже на специфических для последнего задачах. Всё правильно до этого момента? Есть возражения? Надеюсь, что нет. Тогда идём дальше. Какое количество CPU выполнит ту же задачу за такое же время, что и один GPU? У вас есть ответ на этот вопрос? Вы можете привести цифры? Если у вас есть такие данные, то давайте - будет что обсудить. Имея данные уже можно вести разговор, сравнивать условия, смотреть, в какой ситуации что выгодней. Может быть в настоящее время действительно для взлома паролей GPU - это наиболее выгодный вариант по всем параметрам. Я не могу это однозначно подтвердить или опровергнуть, ибо у меня нет данных на эту тему, но я и не делаю однозначных утверждений. А вы продолжаете категорично заявлять, что взлом паролей - это однозначно только GPU. Ну если вы так в этом уверены, то приведите данные. Данные о том, что "Если есть алгоритмы эффективного перебора паролей под GPU, то _любое_ CPU-решение априори будет сильно уступать", а не о том, что конкретно 1 GPU на специфических задачах работает быстрей одного CPU. Понимаете о чём я?

Missing-male

Всё ясно, отличить А от Б вы в принципе не способны. Вопрос закрыт.

Missing-male

Ну так это, я ещё в самом первом комментарии описал своё отношение к тому, насколько страшен чёрт, и на что нужно делать упор, чтобы его не бояться :)

Missing-male

Чтобы взломать SSH-сессию нужно как минимум проксировать трафик между клиентом и сервером, а эта уже задача другого уровня. То же самое с беспроводной сессией. Не имея доступа к передаваемым данным, вы не получитие пароли от сервисов и вам придётся подбирать их онлайн. А онлайн вам сначала предложат вводить капчу, а потом забанят по IP. Это так, беглый взгляд на вопросы взлома кроме перебора паролей.

Но что-то мне подсказывает, что это для вас не проблемы, и следующий ваш ответ тоже будет рассказывать о GPU вместо положенного по контексту man-in-the-middle или чего-нибудь такого.

Missing-male

Либо вы действительно считаете, что один GPU подберёт пароли быстрей всего кластера Google, либо вы по прежнему игнорируете отличие А от Б. Что из двух?

Missing-male

И всё это делают школьники из моего подъезда?

Missing-male

> Как минимум это другая тема.

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

> Подключиться к оборудованию и пропускать весь трафик через себя - не представляет сложности.

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

> Вот я вижу безпроводные подключения своего дома - есть все возможности попробовать осуществить противоправные действия

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

Missing-male

Вооот, вы начали понимать вопрос. Идём дальше. А откуда цифра 50? Почему не 100 или не 5? А почему нужно арендавать сервера в облаке каждый месяц? Вы каждый месяц получаете большую базу паролей? Где цифры, где сравнения? Вы можете сколько угодно разглагольствовать про эффективность, но пока у вас не будет цифр, всё это будет пустословием.

Упоминания где и о чём? В Википедии о том, что публичные сервисы типа Amazon можно использовать для взлома паролей? Я думаю, Амазон бы быстро попросил удалить такую "рекламу". Anyway, если вам нужен пример применения распределённых систем для взлома паролей, то вот вам [url=http://www.youtube.com/watch?v=NT0NQtW3-lk]первая ссылка[/url] из гугля. И там ещё много таких примеров.

Missing-male

Нет, но я то живу в своём. Или вы мне предлагаете беспалевно шляться с ноутбуком по чужим подъездам?

Missing-male

А вы попробуйте. Посмотрим, кто прав.

Missing-male

В общем, как обычно - я нелогичен и глуп, а вы знаете всё, хотя данных у вас и нет.

Missing-male

А, вы про opennet? Действительно, где ещё искать упоминиания про MapReduce, как не на сайте системного ПО. Отличный план.

Условия задачи ввели вы. Причём приплели каких-то мифических геймеров. И после этого говорите, что это я добавляю нюансы.

Missing-male
+2

То ли дело в оригинальном посте, то ли в переводе, но текст довольно бредовый - читать сложно, а некоторые высказывания вызывают коллапс головного мозга. Например, порадовала фраза про полное исчезновение интерпретаторов из мейнстрима, учитывая, что HotSpot - та реализация JVM, которая стоит на большинстве компьютеров в мире - предоставляет компилируемо-интерпретируемую среду исполнения. Про invoke dynamic тоже довольно напыщено - новые уникальные возможности и бла бла бла. Clojure, JRuby и др. прекрасно крутились на JVM задолго до 7 версии. invokedynamic - это оптимизация, принципиальных преимуществ эта инструкция не даёт.

Missing-male
+4

Я что-то не понял, а откуда взялся вывод, что Java 8 - это улучшенная Scala?

Missing-male
+4

Спасибо, посмеялся. Scala - это не просто улучшенная Java, Scala - это отдельный полноценный язык со своей философией, коммьюнити, гайдлайном и т.д. Java никогда не станет настолько же строго типизированной, как Scala, иначе это сломает обратную совместимость. Java никогда не начнёт использовать необязательный синтаксис, иначе это поломает сами основы языка. Java никогда не станет community-driven языком, таким как Scala, Ruby, Python или Lisp, иначе это уже будет просто не Java. Так что тут нечему становиться deprecated.

Гораздо более вероятен другой сценарий, при котором Java станет всего лишь одним из многих равноправных языков для JVM.

Missing-male
+1

> что вы имеете в виду под dsl ?

Domain-specific language.

> Это всё общие слова. А никаких конкретных доказательств, что вот Scala решает некоторую задачу в разы эффективнее Java, и потому сейчас все явисты должны пересесть на скалу, я так и не увидел.

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

Во-вторых, что вы подразумеваете под "эффективней"? Эффективней по скорости или памяти? Это невозможно, ибо оба языка компилируются в один и тот же байткод, и на обоих всегда можно написать эквивалентные конструкции. Если вы про количество кода, то попробуйте, например, развернуть следующий Scala код на Java и сравните:

class Point(val x: Double, val y: Double)

Missing-male

> Была как-то мода на всякие rule engines, но сейчас уже толком никто это не вспоминает.

Ахаха, вы продолжаете меня веселить :) DSL далеко не ограничен движками правил. Опустим варианты про сценарии исполнения, которые вы пишете практически на английском и даром получаете компиляцию в язык программирования (сколько у вас займёт времени написать интерпретатор для простейшего языка на голой Java?). Опустим штуки а-ля LINQ. Что действительно круто, так это то, что DSL-enabled языки позволяют вводить новые конструкции без изменения компилятора тогда. Что, если бы в Java не было конструкции synchronized? Как бы вы её реализовали? Довольно запарно, не так ли? Да и использовать её было бы мягко говоря неудобно. Scala же позволяет создавать функции, которые при использовании выглядят и ведут себя точь-в-точь как встроенные конструкции. Это фишка, которой очень гордятся лисперы: "если тебе не хватает какой-то фичи в языке, просто создай её!"

Кстати про Lisp. CLOS - объектная система Common Lisp - полностью реализована как DSL на макросах. Т.е. программисты не выходя за рамки языка, не трогая препроцессор, не копаясь в имплементации вот так просто взяли и ввели новую парадигму в свой язык. В Scala с этим немного посложней, но добавить туеву хучу крутых фич из других языков на ней тоже можно.

> Если вы имеете в виду пример отсюда http://en.wikipedia.org/wiki/Scala_%28programming_language%29, то отличий никаких.

Я имею ввиду именно то, что написал - одну строчку на Scala, которая развернётся в 13 строк чистого кода на Java. А если val изменить на var, то во все 19 строк чистого Java-кода. 1 против 19. И это в коде, который встречается в большом количестве в 95% проектов.

Missing-male

Пардон, как вам сказать более прямолинейно? Вот вам одна строчка на Scala:

class Point(val x: Double, val y: Double)

Всё. Это полное объявление класса. Вместе с конструктором и методами доступа. Эквивалентный код на Java:

class Point {

private final Double x;

private final Double y;

public Point(Double x, Double y) {

this.x = x;

this.y = y;

}

public Double getX() {

return this.x;

}

public Double getY() {

return this.y;

}

}

14 строк, на одну обсчитался. Если добавить 6 строк для сеттеров, то получится 20. И такой код встречается постоянно. В 95% проектов. В количестве дофига раз. Нет, это не код из Википедии, который вы вообще непонятно как притянули, и нет, это не швейцарский нож, которым никогда не пользуются - это то, что необходимо постоянно. Если вы думаете, что это единственный пример, то попробуйте перевести на Java операции с коллекциями, Visitor, ввод/вывод. Да каждая вторая задача.

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

Missing-male
+1

> class Point {public double x;public double y;}

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

> Вы много видели вакансий в местных конторах ? :-)

На dev.by периодически проскакивают, на hh.ru висят постоянно.

Missing-male

> Мне кажется, вы просто не умеете нормально пользоваться Явой

Очень смешно это слышать от человека, который только что предлагал делать поля public :) Вы, кстати, на своих проектах часто так делаете? Или вы по традиции пользуетесь deprecated геттерами и сеттерами? ;)

> Вы хоть сами смотрели что выдаёт эта ссылка ? Учитывая, что половина вакансий - это Epicor Scala, то на сам язык получается вакансий 20, и это на Россию и Украину :-)

Вы хотели найти работу на Scala, так? Так. Я вам дал список вакансий. Я показал, что у нас Scala тоже используется. Я рассказал про крупные мировые компании, которые делают основной упор на этот язык. Что ещё вам непонятно насчёт работы на Scala? Практически любые варианты, бери нехочу. Что ещё вам непонятно насчёт работы на Scala?

Про industry standard мы вроде бы уже говорили.

Missing-male

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

Missing-male

Равно как и генераторы геттеров и сеттеров, но это уже костыли извне. Сам язык от этого не становится менее многословным. Кроме того, геттеры и сеттеры позволяют контролировать доступ к полям (например, разрешать чтение, но запрещать запись), так же, как и ключевые слова var и val в Scala, но не public поля в Java.

Missing-male

> Добавляйте лямбды, concurrent collections, pattern matching, да всё что угодно, только с новыми ключевыми словами.

Ага, а-ля бессмысленного и беспощадного diamond syntax.

Missing-male
+1

Кхм. Экология и взгляд в будущее - это, конечно, хорошо, но аргументация Вуда, мягко говоря, страдает.

Начнём с ELIZA. Технически простая? Ну, если дизайнер говорит, что регулярные выражения над естественным языком - это просто, то конечно, ваще легко. Программа для диагностирования болезней? А ничего, что это были первые попытки создать естественноязыковой интерфейс, проводимые в рамках исследования вопросов искусственного интеллекта в MIT? Область психологии была выбрана исключительно потому, что в ней можно было поддерживать беседу при очень слабом понимании темы разговора. Большинство пациентов думали, что общаются с реальным доктором?? Ну ппц, оказывается тест Тьюринга уже 50 лет как пройден, а никто и не в курсе. Если несколько поциентов после пары минут разговора повелись на развод про реального доктора, это ещё не значит, что программа была действительно правдоподобна.

Дальше читаем: "выросла из идеи «гуманизма», которая уходит корнями в античную Грецию и ранее христианство". Во-первых, вниманию переводчика, не "ранее", а "раннее", ибо христианство возникло гораздо позже "античной Греции". Во-вторых, христианство стало развитием неоплатонизма, которое, в свою очередь, развилось как новая ветвь учения Платона, а уже Платон говорил о мире идей, что не особо согласуется с гуманизмом. За 5 веков между Платоном и возникновением христианства от идеи гуманизма в религии не осталось почти ничего.

Про Apple тоже круто. Когда это Джобс прогибался под пользователей? Наоборот, он говорил о том, что нельзя слишком прислушиваться к мнению своих клиентов.

Дальше вникать не стал. Если продвигать идеи, то по крайней мере неплохо было бы хорошо знать факты, приводимые в виде доводов.

Missing-male
+12

Как говаривал один знакомый менеджер, задача PM'а состоит в том, чтобы обеспечить получение заказа, сдачу проекта и не мешать программистам между двумя этими событиями. Тем не менее, на первом и последнем этапах менеджер действительно критически нужен. PM - это человек, который при самой адской ж*пе на проекте будет приходить к заказчику и говорить "хорошие новости!"; человек, который всегда на связи, даже если заказчик захочет в 3 часа ночи посмотреть прогресс на проекте; человек, который получает за программистов люлей и при этом всё равно поддерживает позитивный настрой. Не то, чтобы программисты сами не могли справится с этими задачами, но многим ли инжеренам хочется отрываться от технических деталей ради получения очередной порции ректального удовольствия? ;)

Missing-male

Необходимость в вычислительных ресурсах растёт, а вертикальное увеличение производительности имеет свои пределы, причём эти пределы уже близки - скорость процессоров и шин данных подходит к физическому пределу, оптимизаций больше, чем делает gcc, выдавить почти невозможно, а сопроцессоры подходят далеко не для всех задач (да и они имеют свой предел производительности). Параллельные системы дают довольно простой способ увеличить производительность до нужного уровня. Что касается конкретно задач, то их масса на любой машине: когда вы запускаете свою любимую IDE, она наверняка в бэкграунде индексирует ваш код или делает другие проверки; браузер проверяет соединение, подгружает контент и выполняет скрипты в отдельных потоках, да ещё и для каждой вкладки; даже обычный музыкальный плеер продолжает играть текщий трек, пока вы взаимодействуете с его интерфейсом, выбирая следующий.

Missing-male

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

По поводу i7, я тоже не видел, чтобы все ядра были загружены, но при этом некоторые программы прилично так тормозят. И я вполне уверен, что если бы те же программы обрабатывали данные параллельно, то никаких тормозов на 8 ядрах не было бы.

Missing-male
+1

Язык формирует способ нашего мышления (с) Ворф. Если вы пишете программу на языке, изначально заточенном под многопоточность, вы будете легко и с удовольствием добавлять конструкции для поддержки параллелизма. А если вы пишете, скажем, на C/C++, где даже создание нового потока - нетривиальная задача, и при этом у вас нет острой необходимости параллелить вычисления, то вы будете всячески избегать сложностей, связанных с многопоточность. Так и получается, что музыкальный плеер грузится 30 секунд, при этом загружая 1 процессор на 100% и оставляя другие 7 свободными.

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

Missing-male
+1

Как мне кажется, проблема не в самом по себе существовании аутсорс компаний, а в том, что их гораздо больше, чем компаний других типов. Это формирует отношение ко всей отрасли. Где-то месяц назад пришлось доказывать профессору из MIT, с которым вероятно будем сотрудничать, что у нас тоже есть люди, способные писать серьёзные вещи, а не только говнокодить. Но не только западные коллеги и заказчики считают наших разработчиков технически слабыми. Гораздо хуже, что так считают сами разработчики: студентов с первых курсов университетов приучивают к мысли, что белорусский IT - это аутсорс, техническая реализация логики, продуманной американскими или европейскими коллегами. В итоге и само обучение в области computer science сводится к подготовке кадров для Эпама и Итранзишн.

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

Missing-male

Студентов всяких Стэнфордов и Гарвардов с удовольствием забирают к себе Гугли, Фейсбуки и прочие продуктовые компании из top 100. Вопрос не в том, студент или не студент, вопрос в том, готов ли кандидат к работе над сложными задачами, и что делать с теми, кто не готов. А ответ тут простой - делать так, чтобы после университета эти люди _были готовы_ к работе в том числе и в продуктовых компаниях.

Missing-male

Давайте, что ли, по пунктам:

1. Есть, условно говоря, три типа компаний: продуктвые, аутсорсинговые (экспорт простых задач для экономии денег) и просто выполняющие заказы (тот же экспорт, но с более сложными задачами и немного другими деньгами). Риск в продуктовых компниях однозначно выше, отличий в рисках для последних двух типов компаний я не вижу.

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

3. Никто не отрицает заслуги аутсорсинговых компаний. Это и развитие IT сектора (хоть какое-то), и хорошие вливания в экономику, и многое другое. Но существует проблема, и если её решить, то выиграют все.

Missing-male
+1

Вы очень урезаете свои мысли, считая, что собеседник сам догадается, о чём идёт речь. Какая конкретика вам нужна? Вопрос был в том, что делать с джуниорами, которые ничего не умеют, если все компании вдруг станут продуктовыми и не смогут содержать ничего не умеющих студентов. Правильно я вас понял? Ответ: поднимать систему образования до такого уровня, при котором студенты 4-5 курсов уже готовы к работе в продакшене над высокотехнологическими проектами. Возможно ли такое? Да, возможно, примеры - Stanford, Harvard, MIT, etc.

Missing-male
+1

Ой, я хотел ответить, а потом посмотрел на вашу карму. Пожалуй, лучше не буду.

Missing-male

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

Missing-male

1. Насколько я понимаю, для аутсорсеров, работающих по fixed price, риски чисто технические - не уложиться в сроки и/или бюджет. Но это, опять же, зависит от уровня разработчиков и менеджеров. А тут уже без разницы, в какой стране это происходит. Или я что-то не так понимаю?

2.

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

b. В чём здесь отличие аутсорсинговых компаний от высокотехнологических? С бюрократие, законодательством и т.д. нужно бороться в обоих случаях, и аутсорсеры вроде нормально с этим справляются.

Проблема поиска умных людей не специфична конкретно для нашей компании - у нас впринципе не так много людей, понимающих, как делать серьёзные продукты. Спросите у своих, сколько из них знает, что такое AST, как посчитать дисперсию или какие существуют неблокирующие способы синхронизации. Если больше 20% людей ответит на все три вопроса, то это уже будет очень круто. Причём студенты старших курсов, как правило, ещё что-то вспоминают со своих пар в университете, но через год-два упорного труда над написанием HTML страниц и запросами к базе данных и эти смутные воспоминания стираются.

3. Ну, о том, что возможно, а что невозможно, спорить не буду - всё равно это будут только домыслы и сферические четвероногие. Моё сугубо личное мнение, что попробовать всё-таки стоит.

Missing-male

2.b. Хороший аргумент. Но, с другой стороны, кто мешает зарегистрировать компанию в стране с более благополучной обстановкой, а людей нанимать здесь? Отжать бизнес в такой ситуации становится на порядок сложней, а про схемы отжатия офиса с сотрудниками без отжатия самого бизнеса я как-то не слышал. (Хотя я не то, чтобы сильно разбирался в этом вопросе, так что если у вас есть примеры, буду рад услышать).

Про алгоритмистов - это хорошо. Как раньше говаривали на руси, респект и уважуха :) Но, как вы сами сказали, на интервью на такие вопросы отвечает один из N человек. Помнится, после 5 лет обучения в университете всего несколько моих одногрупников знали, что такое асимптотическая сложность, хотя API основных библиотек Java/C#/другого профильного языка знали почти все. Естественно, после этого получаются Java/C#/smth-else разработчики, но никак не полноценные инженеры.

AST = Abstract Syntax Tree = промежуточное представление программы практически во всех компиляторах/интерпретаторах. Мы сейчас как раз делаем ряд проектов по статическому анализу кода, так что может быть в ближайшее время распишу эту тему подробно.

3. А, не, я не предлагаю готовое решение проблемы. Это скорее абстрактная зарисовка про параллельную вселенную, где нет аутсорсных компаний, и про то, как бы там всё могло быть устроено. У меня есть некоторые соображения насчёт конкретных шагов, но это тема для отдельной большой дискусии :)

Компании

Название Рейтинг Отзывы
4.9 0.0 8
4.8 0.0 11
4.8 0.0 13
4.8 0.0 19
4.7 0.0 5
Все компании

Зарплаты

1300
Медиана зарплаты в ИТ за 3 месяца
ДЕК
ЯНВ
ФЕВ
МАР
АПР
МАЙ
1475
1525
1500
1200
1200
1500
© 2008-2017 Частное предприятие "Дев Бай"
Использование материалов, размещенных на сайте, разрешается при условии прямой гиперссылки на dev.by. Ссылка должна быть размещена в подзаголовке или в первом абзаце публикации.
datahata — хостинг в Беларуси