Небольшой оффтопик. Сравнивая разные кроссплатформенные библиотеки, мне больше всего тоже нравится wxWidgets, потому что она использует нативные контролы. Qt, конечно, богатая библиотека, но все-равно не то (контролы собственные), плюс необходима лицензия для коммерческих приложений.
Используя соотвествующие алгоритмы, конечно. Напомнило мне вопрос к Гвидо: как отсортировать миллион 32-битных целых используя 2 мегабайта памяти. Вот его ответ: Sorting a million 32-bit integers in 2MB of RAM using Python Вкратце: используя merge-sort и временные файлы (естественно, при условии что оригинальный список тоже в файле, т.к. в памяти он не поместится).
R очень популярен в Big Data (по крайней мере, на западе), на нем прототипируют, а потом переписывают на Python, Scala или другой язык программирования, более пригодный для разрабатываемой платформы. С развитием Apache Spark уже появилась возможность использовать R непосредственно в production (SparkR), так что прогресс на месте не стоит.
GPU instances использовать в AWS дороговато, поэтому многие не особо заморачиваются, но опять-таки прогресс идет, и на последнем Spark Summit уже обсуждали поддержку GPU: GPU Support In Spark And GPU/CPU Mixed Resource Scheduling At Production Scale Как я понял, в случае R это было бы: Spark создает RDD, R использует GPU для вычислений фаз DAG (используя соответствующие пакеты или непосредственно через Rcpp). Но могу быть не прав, без экспериментов не скажу насколько это практично.
Позвольте возразить насчет «люди обычно сами способны понять». Эффект Даннинга-Крюгера никто не отменял, и иногда можно дать и общеполезный совет, и он не пропадет зря. Это хорошо видно на примере StackOverflow, когда задают одни и те же вопросы. Да, можно просто проигнорировать, подумать — «да это и все так знают, очередной нуб, даже не хочу связываться». Потом этот «нуб» не получив ответ (и не умея гуглить, навыков хватило только на SO), залепит свой велосипед, потом его папа продвинет это на уровень повыше, а потом мы удивляемся — «ну как так 1С и другие поделки вообще появляются на свет???»
Nice article, thanks :) It was surprising for me that workplaces in Europe are not so good, working in North America (Canada in particular) we have a different situation — companies do appreciate their employees, otherwise they couldn't keep them. I guess the reason is thriving IT industry and a lof of competition.
Also it's easy to advance in career and actually many people (including me) chose to «downgrade» their position to reduce the amount of worthless work (projects planning, teams reporting etc) and concentrate on things that actually matters (projects design and coding). Surely we keep the same salary, and employeers understand that we worth more doing what we're best to do rather than management duties.
However, there are «old-style» companies (especially in videogaming industry) with «wage slavery» attitude, but things are changing. Yahoo situation is a good example — Marissa Mayer attempt to move company back to «good ol' style» is quite disasterous. Happy employee is more productive than working excessive hours, tired and mad employee :) Surely salary does matter, but high salary != high quality, and I think more and more employeers realize it when dealing with losing the money because of bad quality (as a cybersecurity specialist it's quite obvious in my area of expertise considering the recent epic failures like Target's, Bangladesh Bank etc).
Это касается только России, на западе если кандидату лет 25, то он на что-то выше junior даже претендовать особо не может. Получить senior к 30 годам — удел единиц, еще многие являются новичками даже в 30 лет. Я проводил собеседования с бесчисленным количеством кандидатов, многие после университета/колледжа ездят по Европам, и получают свою первую работу только лет в 26-28.
Так что это все стереотипы, частично связанные с менталитетом и культурными особенностями. Не надо поддаваться упадническим настроениям, я знаю людей, которые уже в 33 года ставили на себе крест, переставали интересоваться новыми технологиями, и начинали только подсиживать других на карьерной лестнице. Все это приводит только к стрессам и заболеваниям на нервной почве. Можно спокойно работать и до 50 и до 60 лет (но для эффективной работы надо все-таки держать себя в тонусе).
В Северной Америке до сих пор предлагают на выбор мясо или рыбу. Естественно, есть и вегетарианские опции и gluten-free и т.п., но это нужно предварительно предупреждать. Вино тоже вкусное, красное или белое на выбор. Пиво не очень, обычно самое распространенное типа Bud Light.
Единственное исключение, которое я видел за время длительных перелетов — это Air Canada (обычно это единственный вариант перелета между западом и востоком Канады без пересадок). Они действительно предлагают бутерброды и напитки за плату. С другой стороны, никто не мешает предварительно купить что-то в аэропортах, к счастью, цены в них достаточно адекватные.
> Кроме того, с помощью систем автоматизации можно настраивать и величину чаевых, которые будут включены в счет — а значит, официанты будут получать больше (меньше людей уйдет не оставив чаевые).
Э-э-э, а за что чаевые вообще оставлять, если весь заказ автоматизирован? За то, что они принесли еду и питье (что тоже можно автоматизировать). Думаю, в этом случае официантов вообще лучше убрать, или назначить им другую работу (развлекать гостей, если им скучно?).
А в целом, я уже вижу внедрение автоматизации, особенно в сетях быстрого питания. Думаю, скоро студентам уже работы и в McD не будет.
Протестировал на старом железе (Pentium T4500 @ 2.30GHz, 3Gb RAM). В целом распределение такое же для других операционных систем, но относительные величины немного разные. Из-за ограничений в скорости использовал «script 100000 max 100».
Linux Mint 17.1 (3.13.0-37-generic #64-Ubuntu SMP):
Попробовал с 10M. Пришлось выделить больше памяти для Scala (вылетает с OutOfMemory потому что по умолчанию выделяется только 128 Mb или что-то типа того, не хочу врать), так что использовал скрипт как «scala -J-Xmx2g sexy-primes-test.scala 10000000 max»:
Добавил Scala тест. Никаких оптимизаций не делал, код практически один в один. Сразу скажу, что на максимально эффективных алгоритмах Scala немного проигрывает из-за boxing/unboxing. Оптимизацию делать не стал, т.к. в реальной жизни такого рода оптимизации делают редко. Также siev2 не имеет смысла в Scala, т.к. не существует неявного эффективного преобразования из целочисленного в булевое.
Хотелось бы добавить несколько ссылок. Автор явно любит свое PyMNg творение, так что никакие бенчмарки не повлияют на его мнение, однако для других это может быть полезно:
Debian бенчмарки — намного более сложные алгоритмы и хорошее покрытие языков программирования
Что касается PyPy и то, что он где-то «стандарт де-факто» — здесь надо наверное уточнять область. Лично я вижу, что в основном используется CPython, из-за того, что он 100%-совместим со всеми библиотеками, плюс если надо какую-то часть ускорить, всегда можно написать расширение на C (например с использованием Cython). Python выбирают не из-за скорости, тут даже говорить не о чем, а из-за количества доступных библиотек. И в этом плане использование PyPy рискованно, но опять-таки это зависит от области применения.
И наконец насчет Legacy. Я знаю несколько примеров, когда полностью меняли технологический стек, в основном из-за скорости. Одно из хороший решений — использование ZeroMQ, можно разделить приложение на несколько частей (микро-сервисы) и организовать коммуникации между ними (даже если это простой Request-Reply). После этого любой микро-сервис можно переписать на другой язык программирования и уже имея две версии, делать сравнения и анализ.
Естественно, не зря современный стандарт — 80/120 (и ситуация намного хуже для конфигураций, где, например, в том-же JSON-е из-за отсутствия многострочных литералов приходится иногда писать очень длинные строки). Я больше ссылался на разработчиков, которые имея возможность писать короткие строки, тем не менее пишут код длиной до 2800 символов в строке (реальный пример, я сам не мог долго поверить своим глазам и все попытки убедить, что так делать не надо, уперлись в каменную стену фанатичности: «я — snowflake, что хочу то ворочу, и никто мне не указ»).
К сожалению, даже метрики и формальные определения не всегда помогают. Вот, например, один из самых больных для обсуждения требование к стилю — длина строк не должна превышать 80 символов. Несмотря на то, что есть логические предпочтения для этого, абсолютное большинство голосуют против этого: «мы же не в каменном веке терминалов!!!» А то, что:
вообще-то с терминалами до сих приходиться работать (SSH в AWS/другие облака),
code review для длинных строк кода очень тяжело делать (потому что в основном это side-by-side comparison),
некоторые разработчики предпочитают другие layout-ы на экранах — например, иметь консоль с логами от watcher-а (gradle watch, grunt etc) или в целом просто tail -f логами рядом с редактором кода
их не волнует. К сожалению, многие разработчики имеют практически религиозную фанатичность насчет некоторых практик и инструментов, и только голосование (или в худшем случае, когда даже это не работает, официальное требование от руководства) может повлиять на изменение стиля.
P.S. Хотел бы отметить один момент с layout-ами — многие возражают, что сейчас у всех много (2+) мониторов на работе. Тем не менее, современная практика разработки программного обеспечения (не уверен насчет России) включает в себя WFH (Work From Home), и дома у большинства нет лишних мониторов. WFH становится более и более популярным потому что это снижает риск эпидемий на работе (болеешь, можешь сидеть дома и работать, тем самым не теряя зарплату) и современные технологии практически исключили требования иметь всех под боком в любой момент времени.
Позвольте мне указать на некоторые неточности в статье, которые также повторяются в комментариях.
Выделение памяти. free() действительно возвращает память в систему, но не во всех случаях, и уж тем более про это можно забыть если память сильно фрагментирована. Более подробно (с нужными ссылками на документацию) это описано здесь: Linux: Native Memory Fragmentation and Process Size Growth
Unlike certain Java garbage collectors, glibc malloc does not have a feature of heap compaction. Glibc malloc does have a feature of trimming (M_TRIM_THRESHOLD); however, this only occurs with contiguous free space at the top of a heap, which is unlikely when a heap is fragmented.
Если есть проблемы с памятью, то лучше переключиться на другие аллокаторы, например, jemalloc — он используется в Mozilla, Facebook, во многих высокопроизводительных и встроенных системах.
clone (системный вызов sys_clone). К сожалению, здесь очень много неточностей:
fork() не является подобием clone(), это обертка над ним (man 2 fork: Since version 2.3.3, rather than invoking the kernel's fork() system call, the glibc fork() wrapper that is provided as part of the NPTL threading implementation invokes clone(2) with flags that provide the same effect as the traditional system call.)
clone() не делает адресное пространство общим, это все конфигурируется опциями (man 2 clone: If CLONE_VM is not set, the child process runs in a separate copy of the memory space of the calling process at the time of clone().)
Это не упоминается в статье, но был вопрос в комментариях: pthread использует clone (man 7 pthreads: Both threading implementations employ the Linux clone(2) system call.) Но в общем случае для реализации многопоточности хватит и прямого использования clone (Minimalistic Linux threading)
В целом документация есть на все, но это надо знать где смотреть. Опыт работы над встроенными системами научил меня всегда смотреть на документацию API, даже такую элементарную как malloc()/free(). Вот, например, из документации fclose (казалось бы, какие тут могут быть сюрпризы, по крайней мере, с позиции Junior/Intermediate разработчика): Note that fclose() only flushes the user-space buffers provided by the C library. To ensure that the data is physically stored on disk the kernel buffers must be flushed too, for example, with sync(2) or fsync(2).
Машинное обучение не только теоретически, но и практически реально и более того, оно используется для защиты от мошенничества. Да, есть много нюансов, и вопрос производительности является одним из самых острых. Но современные Big Data системы очень сильно с этим помогают, вот например статья: Real Time Fraud Detection with Sequence Mining
Что касается 1 и 0 (мошенничество или нет) — такой подход не особо гибкий. В общем случае система может передавать клиенту число (пусть будет 0-100%), и клиент уже решает что с этим делать. Например (выдуманный пример), если это 80%, то транзакция помечается как требующая подтверждения покупки телефонным звонком, если это 60% то включается дополнительная аутентификация (скажем, подтверждение покупки через электронную почту) и т.д. Но для ознакомительных целей разделение да/нет вполне подходит.
Использую fish уже около четырех лет, и основная причина — поставил и забыл, не надо ковыряться в конфигурациях, ибо предустановки уже достаточно хороши для повседневных нужд. Поддержка Mac OS X является также немаловажным фактором, т.к. это основная операционная система для работы в моем случае.
Что касается скриптов, то я явлюсь сильным сторонником мнения, что программы должны писаться для человека, а не машины. Поэтому bash вообще не использую, все скрипты пишу на Python. У этого подхода есть и плюсы и минусы, но в долгосрочной перспективе (например, сборочные скрипты для Jenkins) это себя оправдывает, как минимум в моем случае. Если же нужно запустить bash-однострочник, ничто не мешает запустить bash напрямую и выполнить в нем команду.
Так что не волнуйтесь насчет RTFM-комментариев. У каждого человека своя уникальная ситуация — когда маленькие дети не дают нормально выспаться и работы невпроворот, уже не до чтения мануалов и настройки конфигураций, надо чтобы работало здесь и сейчас, и можно было сосредоточиться на своих основных обязанностях, как например, веб-разработка в вашем случае.
Python, для графики — www.codeskulptor.org/ (часто используют в учебных заведениях Америки, как минимум в колледжах и университетах Сан-Франциско). Для новичков это идельный язык, очень низкий порог вхождения, намного ниже чем в JavaScript. И это не потому что JavaScript сложнее, а потому что у него очень ограниченная функциональность без сторонних библиотек. Как объяснять студентам разные виды контейнеров, когда в JS их только два, а для всего остального нужно использовать либо библиотеки, либо писать самому. Плюс всякие map/reduce операции и т.п. Конечно, можно ориентироваться на новейший EcmaScript, который намного богаче, но он и сложнее.
В любом случае, решать вам, и если вы приняли решение, то опросы и дискуссии ничего не поменяют, просто хотел дать знать, что используется в Америке.
С точки зрения hardcore vs casual, ситуация с PvP намного проще — это исконная вотчина hardcore-игроков, и в основном разработчики занимаются балансом, а не про упрощением. Но некоторые изменения баланса можно рассматривать как уменьшение сложности:
— bolster (уравнивание обмундирования). Я даже помню когда это ввели в SWTOR (для уровней меньше последнего они обнуляют Expertise, которая дает PvP преимущество), hardcore-игроки в знак протеста бегали «голыми» (снимали всю броню), но ситуацию это не поменяло.
— разграничение по рангу PvP (игроки, имеющие высокий рейтинг, могут соревноваться только с теми, кто тоже имеет высокий рейтинг)
— разграничение по уровню (низкоуровневые игроки соревнуются между собой, высокоуровневые соответственно только с высокоуровневыми).
Небольшой оффтопик. Сравнивая разные кроссплатформенные библиотеки, мне больше всего тоже нравится wxWidgets, потому что она использует нативные контролы. Qt, конечно, богатая библиотека, но все-равно не то (контролы собственные), плюс необходима лицензия для коммерческих приложений.
GPU instances использовать в AWS дороговато, поэтому многие не особо заморачиваются, но опять-таки прогресс идет, и на последнем Spark Summit уже обсуждали поддержку GPU: GPU Support In Spark And GPU/CPU Mixed Resource Scheduling At Production Scale Как я понял, в случае R это было бы: Spark создает RDD, R использует GPU для вычислений фаз DAG (используя соответствующие пакеты или непосредственно через Rcpp). Но могу быть не прав, без экспериментов не скажу насколько это практично.
Nice article, thanks :) It was surprising for me that workplaces in Europe are not so good, working in North America (Canada in particular) we have a different situation — companies do appreciate their employees, otherwise they couldn't keep them. I guess the reason is thriving IT industry and a lof of competition.
Also it's easy to advance in career and actually many people (including me) chose to «downgrade» their position to reduce the amount of worthless work (projects planning, teams reporting etc) and concentrate on things that actually matters (projects design and coding). Surely we keep the same salary, and employeers understand that we worth more doing what we're best to do rather than management duties.
However, there are «old-style» companies (especially in videogaming industry) with «wage slavery» attitude, but things are changing. Yahoo situation is a good example — Marissa Mayer attempt to move company back to «good ol' style» is quite disasterous. Happy employee is more productive than working excessive hours, tired and mad employee :) Surely salary does matter, but high salary != high quality, and I think more and more employeers realize it when dealing with losing the money because of bad quality (as a cybersecurity specialist it's quite obvious in my area of expertise considering the recent epic failures like Target's, Bangladesh Bank etc).
Так что это все стереотипы, частично связанные с менталитетом и культурными особенностями. Не надо поддаваться упадническим настроениям, я знаю людей, которые уже в 33 года ставили на себе крест, переставали интересоваться новыми технологиями, и начинали только подсиживать других на карьерной лестнице. Все это приводит только к стрессам и заболеваниям на нервной почве. Можно спокойно работать и до 50 и до 60 лет (но для эффективной работы надо все-таки держать себя в тонусе).
Единственное исключение, которое я видел за время длительных перелетов — это Air Canada (обычно это единственный вариант перелета между западом и востоком Канады без пересадок). Они действительно предлагают бутерброды и напитки за плату. С другой стороны, никто не мешает предварительно купить что-то в аэропортах, к счастью, цены в них достаточно адекватные.
Э-э-э, а за что чаевые вообще оставлять, если весь заказ автоматизирован? За то, что они принесли еду и питье (что тоже можно автоматизировать). Думаю, в этом случае официантов вообще лучше убрать, или назначить им другую работу (развлекать гостей, если им скучно?).
А в целом, я уже вижу внедрение автоматизации, особенно в сетях быстрого питания. Думаю, скоро студентам уже работы и в McD не будет.
Linux Mint 17.1 (3.13.0-37-generic #64-Ubuntu SMP):
Windows 7 (7601.win7sp1_gdr.140303-2144):
В обоих тестах были использованы ванильные версии: Python 3.2.5 [PyPy 2.4.0], Scala 2.11.6 (Java 1.8.0_45).
PyPy3: Python 3.2.5 [PyPy 2.4.0 with GCC 4.2.1]
Scala: 2.11.6 (Java HotSpot(TM) 64-Bit Server VM, Java 1.8.0_40)
Я перезапустил скрипты с большим количеством итераций (100 итераций), чтобы минимизировать разброс:
Еще хочу попробовать на своем старом ноуте, есть подозрение, что операционная система может влиять тоже. Отпишусь позже.
Результаты для "$ script 100000 max 1000":
Что касается PyPy и то, что он где-то «стандарт де-факто» — здесь надо наверное уточнять область. Лично я вижу, что в основном используется CPython, из-за того, что он 100%-совместим со всеми библиотеками, плюс если надо какую-то часть ускорить, всегда можно написать расширение на C (например с использованием Cython). Python выбирают не из-за скорости, тут даже говорить не о чем, а из-за количества доступных библиотек. И в этом плане использование PyPy рискованно, но опять-таки это зависит от области применения.
И наконец насчет Legacy. Я знаю несколько примеров, когда полностью меняли технологический стек, в основном из-за скорости. Одно из хороший решений — использование ZeroMQ, можно разделить приложение на несколько частей (микро-сервисы) и организовать коммуникации между ними (даже если это простой Request-Reply). После этого любой микро-сервис можно переписать на другой язык программирования и уже имея две версии, делать сравнения и анализ.
их не волнует. К сожалению, многие разработчики имеют практически религиозную фанатичность насчет некоторых практик и инструментов, и только голосование (или в худшем случае, когда даже это не работает, официальное требование от руководства) может повлиять на изменение стиля.
P.S. Хотел бы отметить один момент с layout-ами — многие возражают, что сейчас у всех много (2+) мониторов на работе. Тем не менее, современная практика разработки программного обеспечения (не уверен насчет России) включает в себя WFH (Work From Home), и дома у большинства нет лишних мониторов. WFH становится более и более популярным потому что это снижает риск эпидемий на работе (болеешь, можешь сидеть дома и работать, тем самым не теряя зарплату) и современные технологии практически исключили требования иметь всех под боком в любой момент времени.
Выделение памяти. free() действительно возвращает память в систему, но не во всех случаях, и уж тем более про это можно забыть если память сильно фрагментирована. Более подробно (с нужными ссылками на документацию) это описано здесь: Linux: Native Memory Fragmentation and Process Size Growth
Если есть проблемы с памятью, то лучше переключиться на другие аллокаторы, например, jemalloc — он используется в Mozilla, Facebook, во многих высокопроизводительных и встроенных системах.
clone (системный вызов sys_clone). К сожалению, здесь очень много неточностей:
В целом документация есть на все, но это надо знать где смотреть. Опыт работы над встроенными системами научил меня всегда смотреть на документацию API, даже такую элементарную как malloc()/free(). Вот, например, из документации fclose (казалось бы, какие тут могут быть сюрпризы, по крайней мере, с позиции Junior/Intermediate разработчика): Note that fclose() only flushes the user-space buffers provided by the C library. To ensure that the data is physically stored on disk the kernel buffers must be flushed too, for example, with sync(2) or fsync(2).
Что касается 1 и 0 (мошенничество или нет) — такой подход не особо гибкий. В общем случае система может передавать клиенту число (пусть будет 0-100%), и клиент уже решает что с этим делать. Например (выдуманный пример), если это 80%, то транзакция помечается как требующая подтверждения покупки телефонным звонком, если это 60% то включается дополнительная аутентификация (скажем, подтверждение покупки через электронную почту) и т.д. Но для ознакомительных целей разделение да/нет вполне подходит.
Что касается скриптов, то я явлюсь сильным сторонником мнения, что программы должны писаться для человека, а не машины. Поэтому bash вообще не использую, все скрипты пишу на Python. У этого подхода есть и плюсы и минусы, но в долгосрочной перспективе (например, сборочные скрипты для Jenkins) это себя оправдывает, как минимум в моем случае. Если же нужно запустить bash-однострочник, ничто не мешает запустить bash напрямую и выполнить в нем команду.
Так что не волнуйтесь насчет RTFM-комментариев. У каждого человека своя уникальная ситуация — когда маленькие дети не дают нормально выспаться и работы невпроворот, уже не до чтения мануалов и настройки конфигураций, надо чтобы работало здесь и сейчас, и можно было сосредоточиться на своих основных обязанностях, как например, веб-разработка в вашем случае.
В любом случае, решать вам, и если вы приняли решение, то опросы и дискуссии ничего не поменяют, просто хотел дать знать, что используется в Америке.
— bolster (уравнивание обмундирования). Я даже помню когда это ввели в SWTOR (для уровней меньше последнего они обнуляют Expertise, которая дает PvP преимущество), hardcore-игроки в знак протеста бегали «голыми» (снимали всю броню), но ситуацию это не поменяло.
— разграничение по рангу PvP (игроки, имеющие высокий рейтинг, могут соревноваться только с теми, кто тоже имеет высокий рейтинг)
— разграничение по уровню (низкоуровневые игроки соревнуются между собой, высокоуровневые соответственно только с высокоуровневыми).
Но опять таки, это все баланс.