Мои мысли относительно API на JS основаны на том, что поддерживать один язык для проекта проще, чем два (я не говорю о себе, ведь на Python у меня уже большой опыт, а JS мне придётся подтянуть при разработке клиентской части).
Какие языки/фреймворки/библиотеки вы используете для API сервера?
Вы спрашиваете что-то вроде: «а как мне выкинуть из Catberry основную часть и использовать вместо выкинутого куска React, но так чтобы вы все остальное работало также». Серьезно?
Если я правильно понял, то автор не имел ввиду выбрасывание чего-то из Catberry, а говорил, что ему понравился React, но так как в Catberry были шаблоны, то он ему не подошёл.
С автором Catberry, pragmadash, я пообщался на github, куда я дал ссылку. Но очевидно, что любому автору «своё родное» ближе и понятнее, поэтому я и изучаю взгляды со стороны. :)
Пока что React меня привлекает больше по одной простой причине — за ним стоит Facebook и уже достаточно немалое сообщество, а я в JS мир серверной разработки только сейчас окунаюсь, да и клиентский JS у меня был достаточно костылеобразный (дикие смеси VanillaJS, jQuery и AngularJS...). Кроме того, вслед за ReactJS вполне логичное продолжение изучения идёт в React Native (вот не сложилось у меня с Java для нативной разработки под Android, да и яблочных девайсов у меня больше нет тоже).
Честно говоря, у меня уже мозг пухнет от всего этого разнообразия в JS… Сейчас пытаюсь понять как сдружить Este.JS с реальным миром, где нужна авторизация в API, ну и, собственно, API сервер не пойму на чём писать… С одной стороны раз уже за JS взялся, то логично на нём и API сервер делать, но уж больно сильный соблазн спокойно жить на Python и не мучать себя, хотя и на Python фреймворков для API сервера уже понаписали не один и не два, но всё же меньше, чем на JS :)
Если у вас появятся какие-то комментарии к моему потоку мыслей — я буду очень благодарен.
Знаете ли вы об Este.js? Он очень напоминает вашу солянку. А про Catberry? Он не использует React и Babel, но тем не менее интересен реализацией progressive rendering и изоморфен.
По-моему, в этих туториалах достаточно мало текста и он предельно простой и даже можно просто сам код читать. Я перевёл эту статью, так как она показывает разносторонность языка и чем он может заинтересовать.
Наиболее распространенная задача для KDF — это хеширование паролей. Где требуется усложнить взлом скомпрометированных хешей.
А разве обычный sha-2 с солью не подходит для задах хеширования, сохранения и защиты паролей?
Вы просто не поняли задумку KDF (хотя, стоит отметить, что грань тонка). Задача KDF — сгенерировать вывод, который не только сложно обратить (задача хеш функций), но ещё и удовлетворяющий требованиям случайности последовательности (это требование исходит от алгоритмов шифрования, с которыми как раз и применяют KDF для параметров инициализации). Таким образом да, наиболее распространённая задача KDF — «хеширование» паролей, но не для сохранения в БД (хотя и так можно), а для дальнейшего использование этих «паролей» в качестве входных данных в шифровании.
Внутри компании можно хоть 1ГБ образ использовать, лишь бы все от него наследовались и обновлялись вместе с базовым. Вот на Docker Hub заливать стоит, как мне кажется, только с наследованием от debian (официальный, а не один из 100500 кастомных) или минимальных бразов (scratch, busybox, progrium/busybox, alpine, cirros). К другим базовым образам нужно подходить с полным осознанием, что на debian это не взлетит (FreeIPA, например, имеет только rpm пакеты и все скрипты рассчитаны на Red Hat/CentOS/Fedora и проект достаточно большой) или вам нужна конкретная версия Python, например, тогда целесообразно использовать python:3.2.1-slim.
Да, иногда трудно с Alpine, но я уже спокойно с ним уживаюсь и мне интересно развитие musl libc. У меня есть целый проект, в котором я использую только образы наследованные от Alpine и проект работает замечательно. Всё-таки Alpine помогает иногда понять что на самом деле у моего приложения за зависимости, нужен ли мне bash и тд. Опять же, бывают случаи, например, в Python такое часто, когда модули имеют опциональные зависимости, но в приложении эти функции не используются, но модули будут пробовать подключать эти опциональные зависимости и они будут включены в финальную сборку если пользоваться методом описанным в статье, а в случае минимальных базовых образов такого не случится.
В том-то и дело, что, например, официальный Python образ страдает во многом из-за убогости выбранного базового образа — первая команда у них в Dockerfile: apt-get purge python.*, но это уже не вернёт утраченное место.
Да, найти баланс действительно сложно, Debian всё-таки «привычнее», все знают apt-get и слова поперёк не скажут если в репах не будет какого-то пакета или он будет старый, а вот в Alpine хоть и достаточно много пакетов, но если что-то экзотическое (например из последнего, haskell, которому для сборки себя нужен haskell), то musl libc станет поперёк горла, или просто проприетарные бинарники, которые нужно заталкивать через установку glibc. Но я пока держусь на Alpine и только для особо замороченных случаев (Hadoop, FreeIPA) приходится использовать тяжёлую артиллерию.
Позвольте мне ответить. В таком извращении, которым занимался автор (не переводчик), смысла я тоже не вижу, а вот в минимизации образа я вижу смысл. Только для минимизации образа лучше просто брать маленький базовый образ, например, сейчас мне очень нравится Alpine (5МБ, которые включают busybox и apk пакетный менеджер). То есть /bin/ls вы получаете ценой в 5МБ и тут уже не получится кричать, что образ ужался на 98% (он бы ещё Haskell образ (1ГБ, официальный образ между прочим...) взял ради /bin/ls).
Маленький образ — это меньшее количество уязвимостей. Я уже писал об этом здесь. Судя по всему, нужно дописать уже статью, а то по комментариям хожу проповедую :)
Кроме того, есть две большие разницы — базовый образ внутри компании, который все используют и ничего внешнего не приносят, и образы, которые выложены на Docker Hub, где каждый кто во что горазд (ubuntu, debian, google/debian, fedora, centos — собрать такой зоопарк, если не следить за тем что там авторы наваяли, не составит труда, а это уже 1ГБ, а потом они ещё обновляются кто во что горазд — наследуемые образы НЕ перестраиваются после обновления базового если этого явно не указать в настройках (мало кто указывает)). Таким образом 1ГБ базовых образов можно собрать за первый день и потом в течение месяца из-за обновлений одних образов и не обновлений других — можно новый 1ГБ собрать.
Главное заблуждение: официальные образы на Docker Hub — хороши. Да ничего подобного! Большинство образов на троечку собраны. Самые наглядные примеры:
Python: мои образы основанные на Alpine (50МБ) VS официальный slim (216МБ, а «обычный» — 750МБ) — тыц
Golang: мой образ (126МБ) VS официальный (517МБ) — тыц
(у меня ещё 7 образов есть с аналогичными сравнениями)
Другая мегафича 4.0 ядра — исправлена утечка памяти ядра при мониторинге потребления памяти ядра в Cgroup (вот такой вот каламбур). Спасибо Владимиру Давыдову!
Интересный способ себя занять, это даже более геморно, чем страдания с Alpine образом (5МБ базовый образ — busybox + apk manager).
Для интересующихся: в Alpine используется musl libc, которому просто не хватает поддержки и некоторые вещи (компиляторы и другие крупные/старые проекты) очень сложно собирать, но пакетов уже достаточно много, так что не всё уж так плохо.
Я не говорил, что PhoneGap плох. Я указал на то, что PhoneGap ограничен возможностями WebView, и они, да, будут биться головой о стену до тех самых пор пока WebView не станет производительнее/стабильнее/… (Но я не думаю, что он имеет запас для оптимизации, которую мы сможем заметить визуально, если честно.) То, что крупные компании что-то делают в популярных сообществах — ни о чём не свидетельствует совершенно. Кроме того, в Google Play есть несколько Lite версий их главного приложения и они выпустили Facebook Lite, так что они понимают где находятся границы. PhoneGap несомненно подойдёт для быстрого прототипа, но если вы не считаете, что тормоза вашего приложения у пользователей — это их проблема из-за «слабого прошлогоднего флагмана», то вам очень скоро прийдётся писать нативные приложения (пока что я не видел альтернативы, к моему сожалению).
Ничего удивительного, это ж тормоза и ограничения от WebView. Кстати, с использованием CrossWalk, который позволяет упаковать WebView поновее прямо в приложение, жизнь становится чуть лучше в плане скорости, но иногда приложение просто разваливается…
Я уже неколько лет жду (не горит, так что с Java я мириться не спешу) какой-то альтернативы в области кросплатформенных приложений под мобильные девайсы без компромисов в духе: всё что у вас есть — однопоточный JS, зоопарк версий WebView, ваш HelloWorld весит «всего» 50МБ (утрировано, но 15+МБ — это тоже не идеал), загрузка приложения занимает 5+ секунд.
Контейнеры позволяют изолировать окружение. Вы можете упаковать ваши отдельные сервисы в образы и запускать их «вручную» с указанием локальной папки на конкретном сервере. Контейнеры не сделают вам автоматический S3/HDFS/GlusterFS/WeedFS/NFS/… это уровень приложений.
Кстати, я как-то изучал тему распределённых файловых систем и о GlusterFS всегда были отзывы и конкретные бенчмарки, показывающие, что нужно сторониться этой FS. NFS (не распределённая, но может показаться, что она подойдёт) — не вздумайте полагаться на NFS в проектах (личный опыт). Вы можете даже rsync по расписанию делать из контейнеров, кстати. Я в своё время пришёл к SeaweedFS (WeedFS), но нужно учитывать, что она никогда не будет POSIX-совместимой, но для статики она подходит отлично.
Какие языки/фреймворки/библиотеки вы используете для API сервера?
Пока что React меня привлекает больше по одной простой причине — за ним стоит Facebook и уже достаточно немалое сообщество, а я в JS мир серверной разработки только сейчас окунаюсь, да и клиентский JS у меня был достаточно костылеобразный (дикие смеси VanillaJS, jQuery и AngularJS...). Кроме того, вслед за ReactJS вполне логичное продолжение изучения идёт в React Native (вот не сложилось у меня с Java для нативной разработки под Android, да и яблочных девайсов у меня больше нет тоже).
Честно говоря, у меня уже мозг пухнет от всего этого разнообразия в JS… Сейчас пытаюсь понять как сдружить Este.JS с реальным миром, где нужна авторизация в API, ну и, собственно, API сервер не пойму на чём писать… С одной стороны раз уже за JS взялся, то логично на нём и API сервер делать, но уж больно сильный соблазн спокойно жить на Python и не мучать себя, хотя и на Python фреймворков для API сервера уже понаписали не один и не два, но всё же меньше, чем на JS :)
Если у вас появятся какие-то комментарии к моему потоку мыслей — я буду очень благодарен.
Знаете ли вы об Este.js? Он очень напоминает вашу солянку. А про Catberry? Он не использует React и Babel, но тем не менее интересен реализацией progressive rendering и изоморфен.
На счёт benchmark'ов: github.com/catberry/catberry/issues/168
Меня просто интересует ваше мнение, так как я всё никак не остановлюсь с выбором (просто куча других задач и этот JS у меня не в приоритете пока)
Вы просто не поняли задумку KDF (хотя, стоит отметить, что грань тонка). Задача KDF — сгенерировать вывод, который не только сложно обратить (задача хеш функций), но ещё и удовлетворяющий требованиям случайности последовательности (это требование исходит от алгоритмов шифрования, с которыми как раз и применяют KDF для параметров инициализации). Таким образом да, наиболее распространённая задача KDF — «хеширование» паролей, но не для сохранения в БД (хотя и так можно), а для дальнейшего использование этих «паролей» в качестве входных данных в шифровании.
python:3.2.1-slim.Да, иногда трудно с Alpine, но я уже спокойно с ним уживаюсь и мне интересно развитие musl libc. У меня есть целый проект, в котором я использую только образы наследованные от Alpine и проект работает замечательно. Всё-таки Alpine помогает иногда понять что на самом деле у моего приложения за зависимости, нужен ли мне bash и тд. Опять же, бывают случаи, например, в Python такое часто, когда модули имеют опциональные зависимости, но в приложении эти функции не используются, но модули будут пробовать подключать эти опциональные зависимости и они будут включены в финальную сборку если пользоваться методом описанным в статье, а в случае минимальных базовых образов такого не случится.
apt-get purge python.*, но это уже не вернёт утраченное место.Да, найти баланс действительно сложно, Debian всё-таки «привычнее», все знают apt-get и слова поперёк не скажут если в репах не будет какого-то пакета или он будет старый, а вот в Alpine хоть и достаточно много пакетов, но если что-то экзотическое (например из последнего, haskell, которому для сборки себя нужен haskell), то musl libc станет поперёк горла, или просто проприетарные бинарники, которые нужно заталкивать через установку glibc. Но я пока держусь на Alpine и только для особо замороченных случаев (Hadoop, FreeIPA) приходится использовать тяжёлую артиллерию.
Маленький образ — это меньшее количество уязвимостей. Я уже писал об этом здесь. Судя по всему, нужно дописать уже статью, а то по комментариям хожу проповедую :)
Кроме того, есть две большие разницы — базовый образ внутри компании, который все используют и ничего внешнего не приносят, и образы, которые выложены на Docker Hub, где каждый кто во что горазд (ubuntu, debian, google/debian, fedora, centos — собрать такой зоопарк, если не следить за тем что там авторы наваяли, не составит труда, а это уже 1ГБ, а потом они ещё обновляются кто во что горазд — наследуемые образы НЕ перестраиваются после обновления базового если этого явно не указать в настройках (мало кто указывает)). Таким образом 1ГБ базовых образов можно собрать за первый день и потом в течение месяца из-за обновлений одних образов и не обновлений других — можно новый 1ГБ собрать.
Главное заблуждение: официальные образы на Docker Hub — хороши. Да ничего подобного! Большинство образов на троечку собраны. Самые наглядные примеры:
(у меня ещё 7 образов есть с аналогичными сравнениями)
Для интересующихся: в Alpine используется musl libc, которому просто не хватает поддержки и некоторые вещи (компиляторы и другие крупные/старые проекты) очень сложно собирать, но пакетов уже достаточно много, так что не всё уж так плохо.
forон будет уведомлять о каждом окончании вложенных операций?Просто если захотите посмотреть на мои поделки на Docker Hub: https://registry.hub.docker.com/repos/frolvlad/
Я уже неколько лет жду (не горит, так что с Java я мириться не спешу) какой-то альтернативы в области кросплатформенных приложений под мобильные девайсы без компромисов в духе: всё что у вас есть — однопоточный JS, зоопарк версий WebView, ваш HelloWorld весит «всего» 50МБ (утрировано, но 15+МБ — это тоже не идеал), загрузка приложения занимает 5+ секунд.
Кстати, я как-то изучал тему распределённых файловых систем и о GlusterFS всегда были отзывы и конкретные бенчмарки, показывающие, что нужно сторониться этой FS. NFS (не распределённая, но может показаться, что она подойдёт) — не вздумайте полагаться на NFS в проектах (личный опыт). Вы можете даже rsync по расписанию делать из контейнеров, кстати. Я в своё время пришёл к SeaweedFS (WeedFS), но нужно учитывать, что она никогда не будет POSIX-совместимой, но для статики она подходит отлично.
Для старта можете сделать:
Презентация этого чуда на PyCon 2015: www.youtube.com/watch?v=PiBfOFqDIAI