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

Вот так вот мы и работаем

>>> Просмотр (3120x4160, 3551 Kb)

Отчего многие его так не любят, что с ним не так? Ну кроме того, что:

1. Нет дженериков, укуренные решения вроде sync.Map interface{} в stdlib как следствие;
2. Базилион способов объявить переменную;
3. Магические функции new() и make(), которые работают только с некоторыми типами;
4. Выбивающиеся из общего стиля ЯП iota вместо enum, <- и ->;
5. Сильно ограниченные константы, пригодные только для базовых типов данных;
6. Кастрированные кортежи;
7. Бесполезность поддержки unicode в коде ввиду того, что экспортированы могут быть только элементы, начинающиеся на символ из ограниченного подмножества;
8. Unicode code point'ы можно складывать как числа;
9. Впиндюренные в сам ЯП, а не в библиотеку «горутины»;
10. Невозможность форка проекта с сабпакетами (он не скомпилируется с помощью go get/go install, официальная рекоммендация - использовать sed);
11. Сообщество, которое в каждом объективном дефекте видит глубокий смысл и большой плюс;
12. Go 2, который не пофиксит ничего из этого, кроме дженериков.

Вроде, не критично всё это, жить можно же?

Привет, ЛОР.

Так получилось, что я давно сюда ничего не писал, и уже начал немного скучать. Давай я расскажу тебе про свой 3d принтер.

На скриншоте запечатлен процесс изготовления пластиковой детали, состоящий из разработки трехмерной модели, преобразования модели в G-code и печати на 3d принтере.

( читать дальше... )

>>> Просмотр (3200x900, 1164 Kb)

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

Я пытался придумать почему я должен отделить django, mysql, nodejs и rethinkdb на четыре разных контейнера и возиться с каждым из них индивидуально и так и не придумал. Плюс, получается, я не могу напрямую использовать salt для управления происходящим внутри контейнера. Я должен рулить докером через Dockerfile (или через API) и, в случае любых изменений, пересоздавать контейнер. Но нужно ли всё это?

Мне не нравится концепция одноразовых однозадачных контейнеров. Я поэтому экспериментирую с salt и dumb-init внутри контейнера. Кто-нибудь ещё так делает? Ну, ясен пень, делает, но есть ли какие-либо разумные доводы против этого?

В общем, у меня мысли совпадают вот с этими: http://highscalability.com/blog/2014/4/8/microservices-not-a-free-lunch.html

Everyone! Listen up! Today... today...

$ apulse <program-name> [program parameters]

https://github.com/i-rinat/apulse — эмуляция PulseAudio. Когда приложение пытается загрузить libpulse.so, ему подсовывают её версию от apulse, в которой реализована часть функций, достаточная, чтобы запустить Skype и некоторый другой софт.