• Нужна ли замена JSON? По следам статьи про KTV
    +1
    Если интересно, по ссылке подробное описание: configtree.readthedocs.org
  • Нужна ли замена JSON? По следам статьи про KTV
    +1
    Какой формат вы используете для конфигурационных файлов

    Использую YAML, но с добавкой собственного синтаксического сахара. Плюс особая постобработка.
  • Онлайн-покупки в РФ могут попасть под запрет
    0
    Не знаю как штатовские магазины, ничего не покупал, но за подписки на сервисы регулярно приходят payment receipts. Как я понимаю, это и есть аналог нашего кассового чека. Так что "у них" уже это все работает.
  • Программирование как изобразительное искусство
    0
    Зря вы так, 1С вполне годный язык для своей области. Проблема там ровно одна — фашисткая лицензия.
  • Бег помогает увеличить количество нейронов в гиппокампе
    0
    Чтобы бегать по асфальту и не травмироваться нужны хорошие беговые кроссовки. Традиционно же бег воспринимается как спорт для бедных — никакой экипировки не требуется.
  • Comment from a drafted post.
  • Comment from a drafted post.
  • Comment from a drafted post.
  • RESTful API — большая ложь
    +6
    Нет, это как раз-таки проблема RPC, что без кодогенератора — никуда. Как принимается решение о том, что использовать? Например, на упомянутом мной проекте было так: бэкэнд — Java, фронтенд — Python. Вопрос: что используем для связки? Java-команда предлагает Thrift: «Вот, смотрите, он быстрый, есть binary-протокол и в документации написано, что Python поддерживается». Ок, соглашаемся. Пишем спецификации, генерируем код. Код — говно, но вроде работает. А потом проект начинает расти и начинаются первые баги. Выясняется, что binary протокол не умет работать с Unicode. Что некоторые классы почему-то не генерируются. И если посчитать сколько времени было убито на поиск багов, на допиливание генератора. А потом перевести это в деньги. А потом показать счет клиенту… Ну вы поняли.

    Я не то чтобы против RPC. Просто у каждой технологии своя область применения. RPC хорош для внутреннего использования, где вы точно знаете на каких ЯП будут писаться клиенты, и что для них существует нормальный кодогенератор. REST же хорош для публичного API, тогда можно ограничиться хорошей документацией, по которой любой желающий сможет написать своего клиента на любом, даже самом экзотичном ЯП.
  • RESTful API — большая ложь
    +4
    Основной плюс REST в том, что любой программист может взять свой любимый язык программирования и за пару часов написать на нем клиента к любому REST-сервису. В случае с RPC, если генератор прокси-классов для любимого языка кривой, то придется либо пилить напильником, либо использовать нелюбимый язык. У меня так было со Thrift 3 года назад. В Java он работал как часы, а в Python — баг на баге. Может быть сейчас и пофиксили, но желания использовать его с тех пор нету.
  • Депутат Виталий Милонов предложил заблокировать Facebook на территории России
    +3
    Как по мне, то фигура он чисто техническая и никаких реальных решений не принимающая. Как в известном стихотворении: «Почему ж он заседает? Потому что жопа есть». А безумствует он именно для того, что бы к своей никчемности привлечь внимание, эдакий «Жириновский 2.0». Что касается реакции сообщества, то тут есть только одна правильная реакция — голосование. Тем кто еще верит в выборы — руками, тем кто уже нет — ногами. Все написанное выше, конечно же, мое субъективное мнение, на истину не претендующее.
  • Депутат Виталий Милонов предложил заблокировать Facebook на территории России
    +25
    Милонов — тролль. Не кормите его, не упоминайте его бред на серьезных ИТ-ресурсах.
  • «Луркоморье» приостанавливает работу
    +2
    Только хотел написать про «глаза Джимми», как вдруг http://lurkmore.to/Lurkmore:Donate
  • Как я нашел лучший в мире язык программирования. Часть Йо (2.72)
    +2
    Хотелось бы узнать мнение автора о D, особенно в сравнения с Nim. Дело в том, что я тоже года два назад столкнулся с вопросом поиска идеального языка и для себя нашел D.
  • Кто придумал электронную сигарету: ретроспективная заметка с восстановлением исторической справедливости
    0
    У меня тоже в первый раз так было. Купил себе eGo. Она постоянно протекала, испаритель слабый — вкуса не хватало. Поэтому бегал курить обычные, раз в пару часов. Подарил ее другу и полностью перешел на табак. А потом мне посоветовали KangerTech AeroTank. Объем хороший, испаритель достаточно мощный. И возни минимум — одной заправки на полдня, а то и больше, хватает. Уже чуть больше года курю только ее. Я это к чему, просто нужно найти девайс который подойдет именно вам.
  • Кто придумал электронную сигарету: ретроспективная заметка с восстановлением исторической справедливости
    +1
    Мозг страдает в первую очередь от удушья, которого от электронной сигареты просто нет. А повышение производительности происходит, как я понял, от повышения проводимости нейронов. Если вы ни разу не пробовали электронные сигареты, то я вам очень рекомендую это сделать. Это реально хорошая альтернатива для тех, кто не хочет бросать курить, но хочет максимально уменьшить вред от курения.
  • Кто придумал электронную сигарету: ретроспективная заметка с восстановлением исторической справедливости
    0
    Я тоже занимался спортом во время курения обычных сигарет, но после того как перешел на парение эффект стал намного заметней. По моим субъективным ощущениям, стало гораздо легче дышать. И если раньше дистанция в 2-3 километра казалась очень длинной, то сейчас, как я уже выше писал, серьезно подумываю о марафоне.
  • Кто придумал электронную сигарету: ретроспективная заметка с восстановлением исторической справедливости
    0
    Ваша правда. Тем не менее, снаружи вони не было и некурящим она никак не мешала. Если с ней и надо было что-то сделать, так это поставить хорошую вытяжку. Помню был в Алма-Ате в командировке, там курилки из себя представляли комнаты 3х3 метра с очень мощной вытяжкой. 6-8 человек могло курить, а дыма в воздухе вообще не было — выдувало.
  • Кто придумал электронную сигарету: ретроспективная заметка с восстановлением исторической справедливости
    0
    Где-то читал, не знаю правда или нет (источник сомнительный), что Че Гевара боролся с приступами астмы при помощи сигар.
  • Кто придумал электронную сигарету: ретроспективная заметка с восстановлением исторической справедливости
    +8
    Я курю более 15 лет. Никотин — это наркотик. Но главная проблема это не он, а смолы. Год назад я поймал себя на том, что я угробил свои легкие. Переболеть бронхитом раз 5-6 за год — норма. Утренний кашель — норма. Задыхаться после поднятия на 5-й этаж — норма. С этим надо было что-то делать. Я решил перейти на электронную сигарету и начать бегать. Первый месяц у меня с кашлем выходило такое, что можно было фотографировать и печатать на пачках сигарет, как антирекламу для впечатлительных. Прошлую осень и зиму я пережил без единого бронхита. Сейчас серьезно подумываю о том, что бы готовиться к марафону. Я все еще иногда курю обычные сигареты (в основном по-пьянке), но потребности в них нет вообще — электронной хватает.

    А почему не бросил? А потому, что никотин обладает одним замечательным свойством — он заставляет мозг лучше работать. Я бросал много раз и каждый раз с одним и тем же результатом. Задача, которую я мог сделать за пару дней будучи курильщиком, занимала у меня же некурящего две-три недели. Грубо говоря я ощущал себя полностью отупевшим. Поэтому для меня электронная сигарета — это меньшее из зол. И дискуссии по поводу возможных запретов меня бесят. Эти запрещальщики просто не знают, о чем говорят.

    А еще хотел бы сказать пару слов про запрет курения в аэропортах. Раньше в Домодедово была курилка, которая совсем не мешала некурящим. Сейчас ее нет. Как результат — прокуренные туалеты. Кому от этого стало лучше? Наверное какому-то чиновнику, который наверх отчитался об «успешной» борьбе с курением. Я как курильщик не против запрета курения в общественных местах. Мне не лениво выйти из кафе на улицу, отойти до урны с табличкой «Место для курения» и там покурить. Но зачем было убирать изолированные курилки в аэропортах?
  • Пещерный человек жил не в пещере
    +5
    Вероятно, имелся в виду данный пост: tema.livejournal.com/1943847.html
  • Ночные кошмары Питона: неявный `this`
    0
    Если коротко, то вы можете написать загрузчик для модулей, которые написаны не на питоне, а вообще на чем угодно. И в процессе загрузки транслировать это в понятный для питона код. А если подробней, то надо статью писать (уже работаю над этим).
  • Ночные кошмары Питона: неявный `this`
    0
    Да, я понял. Я имел ввиду то, что конкретно в питоне, если очень хочется добавить свой сахар, то это возможно сделать штатными средствами.
  • Ночные кошмары Питона: неявный `this`
    0
    Import hooks вам в помощь.
  • Ночные кошмары Питона: неявный `this`
    +11
    Я конечно понимаю, что это все не серьезно, но в коде есть баг — обертка, возвращаемая add_this, должна восстанавливать прежнее значение this перед возвратом результата. Если этого не делать, то вызов метода с неявным this внутри другого такого же метода затрет this первого.

    class C:
        name = 'Alex'
    
        @add_this
        def say(phrase):
            print("{} says: {}".format(this.name, phrase))
    
    
    class Echo:
        name = 'Echo'
    
        @add_this
        def say(c, phrase):
            c.say(phrase)
            print("{} says: {}".format(this.name, phrase))
    
    
    c = C()
    e = Echo()
    e.say(c, "does it work?")
    
    


    Выводит:

    Alex says: does it work?
    Alex says: does it work?
    


    Вместо:

    Alex says: does it work?
    Echo says: does it work?
    


    Что бы исправить, нужно переписать add_this вот так:

    def add_this(f):
        def wrapped(self, *args, **kwargs):
            old_this = f.__globals__.pop('this', None)
            f.__globals__['this'] = self
            result = f(*args, **kwargs)
            f.__globals__['this'] = old_this
            return result
        return wrapped
    


    P.S. Да, мне говорили, что я зануда :)
  • Результаты ежегодного исследования StackOverflow — про технологии, зарплаты, счастье и кофе
    +8
    Не могли бы вы добавить ссылку на статью?
  • Bash Booster — SCM инструмент на чистом баше
    0
    Это на целый пост тянет. Если интересно, напишу.
  • Bash Booster — SCM инструмент на чистом баше
    +1
    Перечитал еще раз второй пункт в вашем комментарии. Парсить JSON или INI при помощи awk — это ад. Изначально в Bash Booster применялся такой подход для Java Properties файлов. Работало не везде. Потому было решено использовать для этих целей Python, т.к. он работает всегда предсказуемо. Ну а раз впилили Python, заодно впилили поддержку INI, JSON и Yaml (если стоит PyYaml).

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


    Почему бы вам не поделиться своим домашним костылем? Думаю можно было бы добавить в модуль read в качестве резервного варианта, если вдруг Python не установлен.
  • Bash Booster — SCM инструмент на чистом баше
    +1
    По первому вопросу. Вероятно, вы не уловили суть той части, где обновляется конфигурация nginx — перезагрузка веб сервера осуществляется по событию. Т.е. создается функция-обработчик события nginx-updated и эта функция вызывается только в том случае, если событие возникло. В чем здесь ценность? Скрипт делает ровно то что нужно: если конфигурация не обновлялась — нет смысла перезагружать сервис.

    Представьте более сложный пример. У нас есть nginx, который отдает статику и проксирует запросы к серверу приложений uWSGI. Под uWSGI крутится несколько веб-сервисов на Python. Веб-сервисы используют MySQL. Настройки nginx, uWSGI, исходный код и конфиги веб-сервисов, а так же миграции модели базы данных лежат в одном репозитории с кодом.

    Задача: сделать автоматический деплой всех обновлений, которые появляются в репозитории.

    Какие действия возможны? Если изменились конфиги nginx — перезагрузить nginx. Если изменились конфиги uWSGI — перезагрузить uWSGI. Если изменились конфиги веб-сервисов — перезагрузить uWSGI. Если изменились исходники веб-сервисов — переустановить их в виртуальное окружение и перезагрузить uWSGI. Если изменилась модель — выключить uWSGI (нужен монопольный доступ к базе), выполнить миграцию, включить uWSGI.

    Если попытаться написать этот скрипт без использования событий ­— получится лапша из операторов if, в которой уже через неделю сам автор без бутылки не разберется.

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

    По второму вопросу. Я не вижу ничего криминального в использовании Python для чтения конфигов. Для каких целей это задумывалось? Есть приложение, которое использует базу данных. Логин/пароль от нее лежат в конфиге приложения. Нужно рядом положить скрипт, который периодически (через CRON) делает резервную копию базы. Что-то вроде:

    mysqldump -u username -p password databasename > dump.sql

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

    Я в своей работе чаще всего использую Ubuntu, Debian или CentOS. На всех из них Python есть. Насколько я знаю, во FreeBSD его нет, но он есть в портах. Из того, что мне приходит в голову, сложности могут возникнуть только с выполнением в Linux на роутере или холодильнике, но в данном случае у вас просто не будет возможности парсить конфиги. Все остальное будет работать без проблем.
  • Bash Booster — SCM инструмент на чистом баше
    0
    Только что проглядел их сайт — за год многое изменилось.

    Первое, что бросается в глаза, появилась возможность скачать готовую сборку под нужную платформу. Например, есть deb-пакеты под Ubuntu. Год назад их не было. Я, конечно, допускаю возможность, что плохо искал, но я их сайт в течении двух недель излазил вдоль и поперек. Если они и были, то прятали их очень хорошо. А про веселую инсталляцию руками я уже выше писал.

    Второе, появился внятный пошаговый туториал для новичков. Этого тоже год назад не было. Было что-то вроде известной картинки «Как нарисовать филина».

    выпилили wiki, который устарел и сбивал с толку

    Я это и имел ввиду, когда сказал про плохую документацию. Если она устарела и на каждой странице написано «купите саппорт» — это разочаровывает.
  • Bash Booster — SCM инструмент на чистом баше
    0
    Конечно простые вещи на таком велосипеде можно сделать, однако что-то сложное уже не уверен.

    А не могли бы вы привести пример чего-то сложного? Возможно, мне удастся убедить вас в обратном.
  • Bash Booster — SCM инструмент на чистом баше
    0
    Опыт годичной давности и сугубо субъективный.

    Во-первых, документация написана маркетологами в стиле «Chef умеет вот так, купите платный саппорт и мы сделаем вам хорошо». Я конечно разобрался, но осадок остался.

    Во-вторых, для установки Chef-solo нужен Ruby. В то время в репозиторях Ubuntu 12.04 был Ruby 1.8.4. Chef на нем заводится отказался без внятных сообщений об ошибках. На установленном через RVM, Ruby 2.1 (или 2.0 не помню точно версию) он заработал, но периодически падал опять же без внятных сообщений. Опытным путем удалось его завести на Ruby 1.9.х. Этого конечно можно было бы избежать, если бы не первый пункт.

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

    Если использовать Chef на Amazon OpsWorks, где все инструменты уже интегрированы и нужно просто подсунуть нужные кукбуки, то таких проблем не возникает. И лично у меня осталось хорошее впечатление от него. Но для одиночных образов в Vagrant у меня нет желания его использовать.

    Еще следует оговориться, что я не администратор, а программист. И мой девопсовский опыт был получен в тот момент, когда я ждал нового проекта, а в соседней команде не хватало инженера по развертыванию. В моей повседневной работе Chef и другие «большие» SCM системы — явный перебор. Все что мне нужно — это настроить виртуалку в Vagrant и положить настройки в репозиторий с кодом, чтобы от остальной команды никогда не слышать: «Не знаю, у меня все работает». Если вас Chef полностью устраивает, значит Bash Booster просто не для ваших задач.
  • Bash Booster — SCM инструмент на чистом баше
    0
    От Chef выгодно отличается тем, что «я быстрей на баше напишу» становится еще быстрей.

    Вообще мое субъективное мнение о Chef следующее: это крутая вещь, когда нужно централизованно развернуть парк серверов (8 и более) на том же Amazon. Но для управления парой-тройкой машин, его использование больше напрягает, чем помогает. Для этих целей этот велосипед и был изобретен. Я и мои коллеги успешно на нем ездим уже полгода и пока довольны.
  • Bash Booster — SCM инструмент на чистом баше
    +1
    Python используется только в модуле read для парсинга INI, JSON, Yaml и Java Properties файлов. Другие модули его не используют, так что зависимость опциональная.

    Кроме того, если уж Python не установлен, то он всегда есть в стандартных репозиториях. Чего не скажешь о Ruby, который из коробки не установлен вообще, а в репозиториях часто лежит древняя версия, под которой половина новых пакетов уже не работает. Ну а, если очень хочется использовать Ruby, вы всегда можете прислать патч для модуля ext.