• Нужен ли python для системных администраторов?

    leahch
    @leahch
    3D специалист. Dолго, Dорого, Dерьмово.
    Нет! Все можно сделать на egrep awk sed и bash. Другого и не нужно.
    Ответ написан
    Комментировать
  • Нужен ли python для системных администраторов?

    POS_troi
    @POS_troi
    СадоМазо Админ, флудер, троль.
    И да и нет.
    Больше толку от хорошего знания баша, остальное уже в сторону девопса пошло.

    У меня Руби и Голанг в ходу.
    Руби для чифа и всяких заманух которые тяжко башить, голанг для быстрого написания всяких сервисов.
    Ответ написан
    Комментировать
  • Нужен ли python для системных администраторов?

    @res2001
    Developer, ex-admin
    Администратору в любом случае полезно владеть программированием. Основной упор, имхо, все таки нужно делать на командный язык оболочки bash/cmd/posh. Подавляющее большинство задач можно решить с их помощью. Но если вы будете знать кроме этого и еще что-то - это будет только вам в плюс.
    Ответ написан
    Комментировать
  • Нужен ли python для системных администраторов?

    @alex-t
    Прогр. в команде rco.ru
    ИМХО питон позволяет относительно единообразно написать некоторые (манипуляции с файлами преимущственно) админские задачи на разных ОС. При этом на каждой ОС сами операции настройки ОС весьма специфичны, и на каждой есть достаточно продвинутые инструменты для администрирования...
    Ответ написан
    Комментировать
  • Нужен ли python для системных администраторов?

    Astrohas
    @Astrohas
    Python/Django Developer
    Питон используют не потому что модно, а потому что удобно. И если он удобен вам то используйте. Если нет то используйте то что вам более удобнее.
    Ответ написан
    Комментировать
  • Нужен ли python для системных администраторов?

    Wolfnsex
    @Wolfnsex
    Если не хочешь быть первым - не вставай в очередь!
    Есть ли реальная выгода от питона в системное администрировании?
    На мой взгляд - да, вполне себе есть. Python - довольно лаконичный язык, в виду чего писать на нем и "стильно/модно/молодежно" и банально удобно, удобно делать множество разных мелочей - например, удобно работать со строками. Ну и ещё он идёт комплектом с большинством дистрибутитвов Linux'а и еже с ними... в виду чего его ещё "удобнее" использовать (т.к. всё нужное уже стоит).

    Знаю, что ряд тулзов написано на питоне, но при этом их можно было бы написать и на других языках.
    Я Вам больше скажу, они были бы ощутимо производительнее, и возможно даже лучше по ряду других параметров, если были бы написаны на Си. И это касается не только каких-то "тулзов", о которых Вы говорите, это касается примерно 99% программ/"тулзов"/etc. Практически что угодно можно написать "на других языках".

    P.S. Всё выше сказанное - исключительно личное мнение и опыт и на истину в последней инстанции - не претендует.
    Ответ написан
    Комментировать
  • Нужен ли python для системных администраторов?

    vvpoloskin
    @vvpoloskin
    Инженер связи
    Когда я и коллеги использовали python вместо баш?
    Когда потребовалось написать бекапилку конфигов на 8k сетевых устройст по snmp.
    Когда надо было набросать простой веб-интерфейс для дежурной смены для примитивного up/down и смену description на этих устройствах.
    Когда надо было проинтегрировать nagios-мониторилку с внешей сторонней базой данных.
    Когда на 600 виртуалок необходимо было поставить разные софтины, перечень и версии которых хранились во внешнем xml-файле
    Когда с увесистой пачки серверов понадобилось провести инвентаризацию типа sfp-модулей

    К чему я это? Если вам хватает bash, радуйтесь и используйте его. Когда будет надо, вы сами придете к python.

    На чистом баше вы замучаетесь делать веб-интерфейс к чему-либо, организовывать взаимодействие с внешними системами/программами, отличными от чистого linux (web, snmp, sql, email, ftp не разовое обращение), обрабатывать вводные данные к системе в форматах сложнее csv (html, xml, json), обрабатывать файлы в нестандартных кодировках, использовать нетекстовые переменные в скриптах (арифметика, дроби, списки, файлы). Боль начнется даже просто тогда, когда появятся файлы с названиями с нестандартными символами (?$!*\+alt-символы), а еще и в левой кодировке (привет mount ftp/samba/sshfs/ntfs и даже вложения к письмам). А еще больнее станет, когда размер своих скриптов превысит хотя бы 500 строк.

    И уже как бонус идет то, что python есть из коробки в deb/rhel дистрибутивах, многие системные утилиты написаны уже на нем. Плагин к apt/yum проще всего сделать на python, даже можно не парясь писать стартап скрипты к сервисам.
    Ответ написан
    Комментировать
  • Бесплатный аналог highcharts.js?

    @Deenamo
    www.amcharts.com потрясающий продукт, но при бесплатном использовании в графике будет висеть ссылочка
    Ответ написан
    1 комментарий
  • Бесплатный аналог highcharts.js?

    kwikpik
    @kwikpik
    Developer
    Приходилось использовать highcharts.js, как замену могу предложить code.google.com/p/flot.
    Ответ написан
    3 комментария
  • Объясните что такое полиморфизм простыми словами ?

    Petroveg
    @Petroveg
    Миром правят маленькие с#@&ки
    Я в шоке, если честно... Вот как ни начинаются вопросы про ООП в Javascript, так руки в ноги и понеслось... Кто Java, кто C# примеры приводит. да ещё портянками суровыми. И каждый приписку делает — дескать в Javascript не так наглядно.

    То есть человек, изучающий Javascript, и никогда не видевший других языков, тут же радостно закивает от вида незнакомого синтаксиса? Вы и взаправду преисполнены веры в такой светлый финал?

    Спрошу всех отвечающих:
    1. Number.prototype.toString() и Object.prototype.toString() — это полиморфизм или нет?
    2. Date.prototype.hasOwnProperty() и Object.prototype.hasOwnProperty() — это наследование или нет?
    3. В чём тогда между ними разница?

    ПыСы. И ещё хочу спросить всех знатоков любых языков, кроме указанного в вопросе — если в темах с тэгами Python, Ruby, PHP, C# я начну строчить куски кода на Javascript, потому мне кажется, что так понятнее, как скоро подписанные на эти тэги попросят меня забанить?
    Ответ написан
    7 комментариев
  • Объясните что такое полиморфизм простыми словами ?

    Deerenaros
    @Deerenaros
    Программист, математик, задрот и даже чуть инженер
    Да ладно, парни. Ну хватит уже, к чему такие сложности? Берём и читаем. Вообще совсем не обязательно читать про архитектуру и абстракции именно по своему языку, хотя javascript в этом плане родился уродом.

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

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

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

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

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

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

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

    Таким образом, абстракция невозможна без инкапсуляции и наследовании, как невозможен полиморфизм без, собственно, наследования. Ну а полиморфизм невозможен ещё и без инкапсуляции, которая банально бесполезна без наследования и полиморфизма. Вот такие тут треугольники с пирогами. Жаль только про пирог наврали. И про день рожденье.
    Ответ написан
    3 комментария
  • С чего начать и как писать Unit-тесты для проектов на PHP?

    disc
    @disc
    веб-разработчик
    Ответ написан
    Комментировать
  • С чего начать и как писать Unit-тесты для проектов на PHP?

    Сначала тесты, потом код! Принцип называется разработкой через тестирование (TDD) .

    Хорошая статья на Хабре
    Ответ написан
    Комментировать
  • С чего начать и как писать Unit-тесты для проектов на PHP?

    janson
    @janson
    PHP-разработчик
    1. установить PHPUnit
    2. научится запускать тесты на PHPUnit. Самые банальные по мануалу. Просто запускать и понять, как они срабатывают.
    3. опробовать подход на небольших учебных задачах (всякие code-kata подойдут, задачи типа FizzBuzz, конвертёр температур из шкалы Цельсия в шкалу Фаренгейта, любые простые, алгоритмизируемые задачи с проверяемым результатом).
    4. После понимания сути тестов, заводим tests/ в реальном проекте, и начинаем думать, как это всё завести. В первый раз достаточно сложно сообразить как всё это добро соединить. Постепенно прикручиваем тесты, осваиваем технику работы со стабами (Stub) и моками (Mock).

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

    Очень вероятно, что с первого раза не всё будет понятно и просто. Пробуйте.

    Как пища для размышлений и осваивания методологии TDD, подборка задач:
    codekata.com

    Во многих там даже условия тестов прописаны, остаётся подкорректировать под себя и принятся за реализацию.
    Ответ написан
    Комментировать
  • Как исправить The requested URL /../.. was not found on this server?

    @vyrkmod
    Пишу на php. И не стыдно.
    Надо велеть апачу дергать index.php если по урлу ничего нет. Как-то так
    <Directory "/var/www/html/site">
        RewriteEngine on
        RewriteCond %{REQUEST_FILENAME} !-f
        RewriteCond %{REQUEST_FILENAME} !-d
        RewriteRule . index.php
    </Directory>
    Ответ написан
    4 комментария
  • Post и Get запросы, какая между ними разница и что лучше и для каких целей?

    socengel
    @socengel
    7 лет native php в продакшене, онлайн 20000+,
    Общего между ними то что они работают одинаково. Разницы между ними технически никакой. А вот идеологические различия есть.

    Я расскажу о них в контексте PHP. Прошу заметить что протокол HTTP к PHP имеет косвенное отношение потому что он создавался для обмена html страницами а PHP просто расширяет возможности и того и другого.

    GET запрос используется чтобы получить данные а POST чтобы отправить. (Напоминаю что технически они работают одинаково).

    Поэтому в контексте PHP опираясь на эту идеологию сделали следующим образом:
    1. При каждом запуске PHP по умолчанию создаются суперглобальные массивы ($_GET, $_POST).
    2. Если в строке запроса есть вопросительный знак(?). То все что после него считается параметрами GET запроса они представлены в формате 'ключ'='значение' и в качестве разделителя используется знак амперсанда (&)
    Пример:
    GET /index.php?name=Андрей&surname=Галкин
    это строка запроса, тут 2 параметра. эти параметры попадут в массив $_GET.
    3. $_POST заполняется другим способом. содержимое этого массива заполняется из "заголовков запроса". То есть из места, скрытого от глаз в явном виде. Всю рутину по созданию таких заголовков берет на себя браузер. Хотя иногда и что-то редактируется в заголовках в ручную.

    Чаще всего пост запрос используется в формах (для отправки данных).

    Например у нас есть форма для входа 2 поля логин и пароль.

    Представим что мы используем GET метод. Тогда при отправке формы мы перейдем на следующий адрес /login.php?login=Андрей&password=123 согласитесь что так передавать такую информацию совсем не безопасно. Любой может открыть ваш браузер и начиная вводить адрес сайта он из истории может увидеть ваши пароли и логины.

    А вот если бы мы указали методом POST то мы бы получили следующий запрос:
    POST /login.php (login=Андрей&password=123) то что в скобочках было бы скрыто и никак не сохранено в браузере.

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

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

    И еще одна хорошая новость их можно комбинировать, например
    POST /index.php?page=login (login=Андрей&password=123) Думаю я уже достаточно объяснил что из этого получится и какие параметры в какой массив попадут.
    Ответ написан
    2 комментария
  • PDO или ORM в PHP?

    m_z
    @m_z
    Ошибка в понимании разницы между PDO и ORM, вопрос звучит как «ложка или тарелка за ужином»

    PDO это DBAL — простой интерфейс для работы с базой данных, который предоставляет одинаковые методы для работы с различными базами данными, поэтому вам не надо задумываться с какой именно БД мы работаем в текущий момент.

    ORM — из википедии — is a programming technique for converting data between incompatible type systems in object-oriented programming languages. Т.е. техника конвертации обычных таблиц, как в реляционных бд, в объекты. Это и очевидно, с обычными массивами работать трудно, а FETCH_OBJECT это всеравно не ОО-подоход.

    Одна технология дополняет другую.

    Теперь про propel и doctrine.

    Doctrine 1 мне не понравился потому, что в него добавили кучу непонятных фич и в конечном результате вышла каша, трудная для изучения (для примера, три способа извлечения данных из сущности, непонятная абстракция 'Table').

    Propel. скорее мертв, чем жив. Его поднял и поддерживает сейчас только один человек. Не понравился тем, что на одну сущность генерируется 6 непонятных классов, да и сам процесс генерации надоедает

    Doctrine 2 это практически hibernate для php %) по сравнению с первой версии его очистили от мусора, сделали его data mapper-ом. Что нравится — это понятный интерфейс, чистые доменные объекты (сущности) — весь конфиг можно вынести в аннотации/xml/yaml. В результате все модели выглядят так же просто, как и class news {private $title; private $text; }. Остановился на нем.
    Ответ написан
    Комментировать
  • PDO или ORM в PHP?

    Rigo
    @Rigo
    Использовал доктрину (в симфони) — удобно, джоины делать можно. Все наглядно и красиво, есть документация.
    Из минусов — потребляет много памяти.
    Ответ написан
    Комментировать
  • PDO или ORM в PHP?

    Parsing
    @Parsing
    Есть такая вещь как форум по php: www.phpclub.ru/
    Где есть поиск, и гораздо больше опытных людей (а не (больше) новичков как на хабре).
    Хотя искренне надеюсь, что и здесь смогут подсказать…
    Ответ написан
    3 комментария