• Что нужно для безболезненного перехода на linux?

    abs0lut
    @abs0lut
    Что нужно для безболезненного перехода на linux?

    Нужна виртуальная машина, чтобы попробовать работать, прежде чем полностью переходить на GNU/Linux.
    Нужна мотивация, ибо "линукс ради линукса" - плохой повод подружиться с ОС.
    Нужно быть готовым к проблемам и трудностям, и, как следствие, уметь гуглить решения проблем.

    Порекомендуйте литературы

    Порекомендую, хотя все чаще встречаю мнение, что она не оправдывает себя, и вся суть в практическом опыте.

    Shotts W. E. Jr. - The Linux Command Line - A Complete Introduction - 2012
    Barrett D.J. - Linux Pocket Guide - 2012
    Brian Ward - How Linux Works - What Every Superuser Should Know (2nd edition) - 2014
    Lewis J.K. - Linux Utilities Cookbook - 2013
    Linux Bible - 8th Edition
    Скотт Граннеман - Linux. Необходимый код и команды. Карманный справочник - 2010
    Эви Немет - Unix и Linux. Руководство системного администратора - 2012

    не лазить по пустякам на форумы

    Думаю, на форумах Вы будете проводить несколько больше времени, чем думаете.
    Ответ написан
  • Что нужно знать чтобы стать начинающим системным инженером (devops)?

    Singaporian
    @Singaporian
    Статья, которую должен прочитать каждый.

    DevOps - не профессия. Это название культуры доставки кода от разработчика (dev) через тестировщиков и до сисадмина(ops) и обратная связь по этой цепочке.

    Человека, который внедряет DevOps, обычно называют... как хотят. Чаще всего этим занимается какой-нибудь нон-конформист в команде.

    Профессии, которые отрисуются в процессе построения этой методологии следующие:
    • Build Engineer - инженер, который управляет зависимостями, сборками, конфликтами кода.
    • Release Engineer - инженер, который управляет репозиторием кода (кто куда и по каким правилам мерджится и откуда бренчуется). Пожалуй, это самая сложная задача в больших проектах. Особенно с нестрогим Agile или в Waterfall.
    • Automation Engineer - инженер, который занимается автоматизацией рутинных задач. Обычно деплоймент, автотесты, etc. Все эти buzz-слова типа Docker - его инструментарий.
    • Site Reliability Engineer - инженер, который поддерживает ops (апгрейды, расширение железа)
    • Configuration Manager - непонятная мне специальность. Жуткое порождение HR-специалистов, давящих на громкое название позиции. Можно было бы пойти дальше и назвать специальность ZooKeeper Vice President

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

    Почти всегда все эти роли совмещают один-два человека. Ну это зависит от качества кода.
    Назовем эту компанию BRAE/CM для краткости.
    Задача BRAE/CM состоит в том, чтобы программный код, который выходит из под пера программистов, оставался на контроле программистов и сисадминов одновременно. Программисты, равно как и сисадмины, благодаря DevOps-подходу, имеют возможность и даже обязаны обслуживать код на протяжении всего жизненного цикла от планирования архитектуры до мусорки.
    То есть сисадмины начинают рулить еще до того, как код попадет к ним - на ранних стадиях, а программисты продолжают рулить своими задачами уже после того, как код от них ушел к сисадминам - на поздних стадиях. И все это прозрачно друг для друга и все проблемы и решения ходят туда сюда и не спотыкаются о бюрократия в стиле "ничего не знаю, мы код уже закоммитили, у меня тут свои проблемы, у них сломалось - пусть сами и чинят".

    Так вот эта работа - завершающая стадия системного администратора и начинающая стадия разработчика. Поэтому не бывает Junior BRAE/CM.
    BRAE/CM бывает всегда только Senior в системном администрировании и всегда Junior в программировании.

    Еще один момент. В домашних условиях можно выучить инструменты на базовом уровне. Но не поварившись в одной кастрюле с реальными разработчиками, смысл всей этой кухни не понять. Так что сразу забейте. Но если хотите, могу описать пошаговый длинный путь как стать RE/CM:

    Сразу оговорюсь по языкам.
    У каждого языка свое предназначение. Java чаще используется в корпоративном секторе. Там много серверов и сложные бизнес-приложения. Поэтому Java-мир очень чувствителен к таким понятиям, как "технинческий долг" и "управление процессом разработки". И именно поэтому именно там все основные вакансии DevOps и именно там будет самый интересный опыт.
    Кроме Java, традиционно сильная DevOps-культура у Ruby. Практически все остальные языки не имеют столь развитой и популярной инфраструктуры в в данном контексте и потому вам скорее всего будут неинтересны.
    Другими словами, если в среде разработчиков выбор языка - тема для холивара и эмоций с миллионами сравнительных анализов с противоположными результатами, то для специалистов по DevOps выбор очевиден и прозрачен. Java - это одновременно самые интересные задачи, самый богатый toolset, самый большой выбор вакансий и самые высокие зарплаты.

    Каждый последующий пункт, кроме особо длинного первого, будет выливаться в неделю-две достаточно плотного труда. Если не прокрастенировать и уделять этому по несколько часов вечером.

    Итак, что делать:
    1) Почитать книги Head First по Java. Пройти курсы Java на EDX.
    2) Освоить SVN. Есть прекрасные тьюториалы. (GIT освоим позже)
    3) Поставить VirtualBox (не VMWare!!!)
    4) Написать простенькое приложение. Код коммитить в SVN. Собирать его при помощи maven.
    5) Поднять на отдельной виртуалке Jenkins. Он должен брать код приложения на SVN и запускать свой локальный maven для сборки.
    6) Написать модульные тесты (unit tests) своего кода. Пусть maven и их прогоняет.
    7) Поднять где-нибудь Nexus. Усложнить задачу maven, чтобы он теперь складывал все в Nexus. Если maven'у потребуются внешние библиотеки, он тоже не сам должен ходить в интернет, а через Nexus (Central repo).
    8) Настроить на своем десктопе vagrant так, чтобы он с нуля создавал виртуалки VirtualBox.
    9) Создать виртуалку DEV через vagrant. При этом ansible должен на ней что-нибудь настроить (например установить JDK)
    10) Научиться деплоить jar/war из Nexus на виртуалку DEV чем-нибудь. Чем - не посоветую, так как сам работаю с очень сложным IBM uDeploy, а это точно не для новичка. Посмотрите в сторону Rundeck или чего-то такого. Может самим Jenkins'ом задеплойте.
    11) Напишите интеграционные АВТОтесты. На чем хотите (как вариант: Selenium).

    Усложняем систему.
    12) Донастраиваем Jenkins: собирает maven-проект; выкладывает на Nexus; дергает vagrant/ansible для создания виртуалки SIT (system integration test); деплоит приложение на SIT; прогоняет автотесты на SIT; удаляет виртуалку после успешного завершения автотестов.
    13) Прикручиваем SonarQube в Jenkins для статического анализа кода. Исправляем косяки своего кода, согласно полученным от SQ рекомендациям.
    14) Прикручиваем мониторинг Sensu.
    15) Пишем нагрузочные тесты на чем-нибудь. В идеале потрогать два инструмента: jMeter и Gatling.
    16) Как и в 12-м шаге прикручиваем в Jenkins автоматизацию создания виртуалки SLT (Stress/Load test) и прогона на ней тестов. Только уже лоад-тестов(обязательно) и стресс-тестов(опционально) соответственно.
    17) Дописываем в свое приложение какой-нибудь функционал, чтобы использовалась база.
    18) Придется познакомиться с LiquiBase. Деплой SQL руками делать запрещено.
    19) Перейти на Docker (то есть теперь приложение выкладывать не напрямую в ОС, а внутрь докера)

    20) Денек на то, чтобы почитать про Agile, Scrum, Waterfall и прочие организационные порядки.

    А теперь немного уходим в управление проектом:
    21) Поставить Atlassian Jira. Разобраться, чем отличаются Epic, Story, Task, Sub-Task. Создать себе подобной этой структуре фронт работ (делать его не придется, просто нафантазируйте).
    22) Поставить Atlassian Stash и связать его с Jira.
    23) Переехать со своего SVN на GIT, предоставленный Stash'ем.
    24) Пройти Git-тьюториал какой-нибудь. Инструмент очень нетривиальный.
    25) Взять любую таску в работу. При этом в начале работы сделать новый Git branch из тикета Jira.
    26) По завершению работы запустить всю построенную ранее цепочку, но уже для своего брэнча.
    Дайте попробую угадать: вам пришлось скопировать все джобы и переписывать в них ветки?
    27) Сделать джобы нормально. Чтобы одни и те же можно было использовать для любых веток - по аналогии с принципом программирования "reuse code". У Вас будет reuse job :)
    28) Сделать pull request, самому сделать code review и самому себя же за-approve'ить. После этого сделать merge своей ветки в master.
    29) Сделать сборку брэнча автоматической по git-hook (или SCM pool)

    30) А теперь высший пилотаж: к чертям Docker, Copistrano и прочую buzz-word-hipsters-галиматью. Теперь вы с этим знакомы и сможете применить, но пришло время выгрызать этот детский сад калёным железом. Теперь вы доставляете код только как .deb-пакеты. Это значит, что вы:
    a) разбиваете control-файл на несколько пакетов, возможно с lib*,
    b) оверрайдите все ~20 dh_ в файле rules так, чтобы все это соответствовало вашим наработкам в предыдущих пунктах.
    c) раскидываете файлы по .install
    d) самое тяжелое: готовите .preinst, .postinst, .prerm, .postrm файлы СОГЛАСНО ИХ ПРИМЕРАМ .ex, сгенерированным dh_make - то есть с разбиемнием на update/configure/broken-install и что там еще есть. Это означает, что при переустановке, при апгрейде, при даунгрейде, при удалении и при пурдже, у вас будут разные сценарии, каждый из которых должен быть проработан досканально. На этом этапе вы также познакомитесь с понятием "регрессионные тесты".

    Ну как бы базовый вариант вот. Но это далеко не весь инструментарий и путь. Это так, для начала.
    Кроме этого неплохо бы познакомиться с Puppet (это не очень подходит для DevOps, скорее для рядовых админов с кучей серверов, но это очень популярный инструмент ввиду того, что никто не понимает, что такое DevOps и вас скорее всего заставят управлять сотней серверов, вместо релиз инжиниринга). А так же нужно познакомиться с операционными системами NixOS (обязательно) и CentOS/Debian (опционально, но я бы палкой бил тех, кто не знает эти OS). Кроме того, надо базово ориентирваться в PostgreSQL.

    Внимание, важный момент, который должен быть вшит на уровень подсознания у DevOps-ориентированного инженера: вы все время пробуете новые инструменты. Вы всегда будете находить что-то очень отличное. Знаете Nexus как свои пять пальцев и он решает почти все проблемы? Отлично! Теперь выкидываете Nexus и ставите Artifactory. Знаете хорошо CentOS? Круто! Теперь пробуете все это проделать на Windows или Debian. Потому что только когда вы сможете сравнивать инструменты, ваша работа будет ювелирной. А DevOps бывает либо ювелирным, либо он не DevOps. Вы должны быть языко-независимым, платформо-независимым и инструменто-независимым.

    Что будет дальше? Дальше вы начнете работать с микросервисами (сотни одинаковых контейнеров в облаке, которые должны как-то работать друг с другом без ручной конфигурации). Тогда познакомитесь со всякими Consul, ZooKepper и кучей инструментов AWS/OpenStack.
    Ответ написан
  • Какую литературу следует выбрать для освоения linux?

    foboss
    @foboss
    Эви Немет. Руководство системного администратора LINUX
    Эви Немет. Руководство системного администратора UNIX

    Очень хорошо помогли в свое время
    Ответ написан
  • Java junior developer кратчайший путь с нуля до реальной работы?

    @lstdayofhmnty
    Если станешь зачитываться теорией - провал тебе обеспечен. Читай и по изученному усиленно пиши код(просто "поглядывать" не катит), иначе далеко не уедешь.
    Не надо тебе больше литературы и ресурсов, не прыгай с одного обучающего материала на другой без крайней на то необходимости, не распыляйся.
    Добавь практику к изучаемому материалу как можно скорее и на ней же сосредоточься, Джавараш подойдёт.
    Загляни на досуге на Гетджаваджоб, рекомендовать не могу - не счупал, но такое есть и вроде у некоторых выстреливает.
    Ответ написан
  • Путь в быдлокодеры или как стать программистом с 0?

    DmitriyEntelis
    @DmitriyEntelis
    Думаю за деньги
    1) Я упорно отказываюсь называть верстальщиков - программистами.
    На 90% это тупая низкооплачиваемая работа, никакого отношения к программированию не имеющая
    Исключения есть, но не много.
    Для того что бы стать web backend программистом - знания верстки нужны самые минимальные (читай - не нужны вообще, но в процессе все равно появятся), зато нужно например sql которого в вашем списке нет почему то.

    2) Если хочется денег и нет отвращения к дресс-коду - можно пойти в java разработчики.
    По деньгам выиграете заметно, но это в 99% enterprise со всеми вытекающими.

    3) Если хочется денег и свободы - можно пойти в разработчики ios/andoid на выбор.
    Самый правильный вариант если с нуля выбирать профессию.
    Кадровый голод в сфере дикий, в dc берут с 0ми знаниями на неплохие деньги.

    Imho самый правильный вариант для Вас - второй или третий.
    Становиться верстальщиком сейчас - явно не самая хорошая идея.

    UPD
    PolzuizYami: Что за enterprise и что за вытекающие? )
    Какой порог входа для разработчика под мобилки и через сколько я смогу показать результат и что то за это начать получать ? Почему вы не любите fronted? ) И почему становится fronted'ом не лучшая затея(на верстке я как бы не собирался останавливаться, но это основа основ для fronted'a)?

    Enterprise - работа или в крупной компании или в аутсорсере который работает на крупную не IT компанию. Вытекает из этого определенный уровень бюрократии, чинопочитания, формализма, дресскода и прочего, что в какой то мере компенсируется кешем и стабильностью™.
    Опять же не всюду, но очень много где.

    Порог входа для мобильной разработки сейчас достаточно низкий, 0-1-2 месяца самостоятельной практики и можно идти на вакансию junior, в dc платят 40-50 на старте, за год-два можно выйти на 150-250+ с учетом фриланса.

    По поводу фронтенда:
    Сразу небольшой дисклеймер:
    a) не хочу никого обидеть, пишу исходя из личного опыта. b) это справедливо не для всех проектов.

    Итак:
    1) В отличии от backend - сложность и объем задач по frontend не зависит от размера аудитории проекта.
    2) В отличии от backend - работы по frontend выполняются быстро и в отсутствии требований по изменениям - доработкам не подвергаются.
    3) В отличии от backend - текущая работа по frontend сильно менее связана с прошлыми этапами работы, либо погружение в проект требует не много времени (не всегда, но часто)
    4) Следствие из 1, 2, 3: Для запуска развития среднестатистического проекта нужны backend разработчики в команду (штат/длительный аутсорс) и не нужны frontend разработчики в команду (проще и дешевле брать фрилансеров под конкретные задачи)
    5) Вывод: Путь верстальщика это в 90% либо короткая дешевая работа на фрилансе, либо работа в штате по поддержке постоянных маркетинговых хотелок (подвиньте банер на 20px в бок, итд), либо в очень редких случаях - действительно сложные, нагруженные с точки зрения frontend проекты.
    Почему в редких случаях? Потому что таких проектов очень мало :) (и кстати многие из них - enterprise)

    UPD-2
    По поводу мобильной разработки:
    Куда пойдет mobile dev через 5 лет - предсказать сложно. На мой взгляд основная масса проектов сейчас достаточно простая и для успешной реализации требует монотонной аккуратной работы (70-80% времени это собирание верстки и анимаций, подключения к внешним апи). Адские зарплаты сейчас обусловлены дикой нехваткой людей. Но есть мнение что пик уже прошел.
    С другой стороны появляются новые мобильные платформы - и разработчики нужны уже под них) Непрерывный процесс саморазвития как он есть)

    UPD-3
    Собственно, почему Веб ,а не мобильная или Java. Ориентировался чисто по вакансиям своего города, к сожалению живу не в DC и да же не в DC2, а наверно DC 666 (Владивосток).
    Вся прелесть бытия IT специалистом - в нашей широкой востребованности. Не нужно ориентироваться на свой город, да и на DC по большому счету не стоит. Перед тобой вся планета.
    да и маме сайт сделаю
    ппц мотивация для выбора жизненного пути.
    Ну а про потолок верстальщика - я расписал ниже.
    Ответ написан
  • Ценится ли IT-специалист, который умеет все?

    @inkvizitor68sl
    Linux-сисадмин с 8 летним стажем.
    Ценятся. Очень.

    Только платят им мало.
    Ответ написан
  • DevOps основные требования к знаниям. С чего начать?

    begemot_sun
    @begemot_sun
    Программист в душе.
    В моем понимании DevOps -- это админ-программист. Больше уклон в строну админства.
    Если админы просто админят.
    Программисты просто программируют.
    то DevOps налаживает процесс, настраивает нужное окружение, делает так, чтобы основные рутиные операции были автоматизированы.

    Соотвественно упор нужно делать на системы сборки, тестирования, развертывания, виртуализации, bash, python и т.п.
    Ответ написан
  • Как повысить карму?

    fessmage
    @fessmage
    Есть два варианта. Либо ты пишешь свое мнение не смотря на то топик это к примеру любителей или ненавистников эппла, и тогда ты всегда получаешь минуса (но зато пишешь что думаешь), тогда не видать тебе плюсовой кармы.
    Либо ты тщательно вымеряешь а где бы что написать так чтобы тебя минующие мудаки не заметили ни в коем случае, подмахиваешь и подстраиваешься под текущее настроение топика и его читателей. Тогда ты накопишь, может быть, плюсов, и в точно такой же манере тебе придется писать все посты и комментарии, чтобы не дай бог не написать чего то с чем минусующие мудаки не согласны. В такой же манере продолжая им подмахивать пока не наберешь больше пары сотен голосов плюсовых в эту сраную карму, тогда уже почти на всё будет пофиг (как бумбуруму сегодня, эпик фейл в этой истории со спамом, а ему похуй, дальше будет теже обзоры ноутбуков и гаджетов писать (хорошие кстати обзоры)) и можно будет снова писать то что думаешь.
    Мне вот претит проходить через второй вариант чтобы писать своё мнение когда я этого хочу, а не когда оно совпадает с мнением минусующих молчаливых мудаков, поэтому я остановился на первом варианте, как побочный эффект имею отсутствие за год с регистрации возможности публиковать пост и комментарий раз в пять минут (пока, а там и раз в час наверное дальше). Причем я не трололо, и стараюсь писать полезные комментарии, и люди соглашаются что это полезные комментарии, это видно по счетчику голосов — их много, но минусующие молчаливые мудаки побеждают в этой борьбе, потому что я не собираюсь подстраивать свое мнение под их струю.
    Ответ написан
  • mac-адрес в ubuntu

    m0sia
    @m0sia
    два варианта:

    1)в NetworkManager в свойствах проводного интерфейса в графе mac address
    2)в /etc/network/interfaces для нужно интерфейса прописать параметр hwaddress
    для примеров можно посмотреть man interfaces.

    auto eth1
    iface eth1 inet static
    address 192.168.1.200
    netmask 255.255.255.0
    hwaddress 11:22:33:44:55:66
    Ответ написан
  • Как повысить карму?

    @bondbig
    поменьше говорить о карме, побольше делать хороших, полезных дел:
    — Писать полезные комментарии
    — Найдя опечатки/ошибки в тексте статьи — отправлять их в личку автору
    — Отвечать на вопросы в q&a
    — Продолжать в том же духе
    Ответ написан
  • Как навести порядок у себя на винте?

    prairie_dog
    @prairie_dog
    Как сказали выше — надо все удалять и не парится. А если не можете удалить, то пишите все на диски, затем приходитесь по ним индексатором (нагуглил ) и нумеруйте диски маркером, после чего убирайте подальше. Когда вам надо будет что-то найти, откройте файл-индексы и поищите с помощью него — у вас будет номер диска и место где лежит нужный файл.
    Ответ написан
  • Пример Qt программы с использованием QStackedWidget?

    Artemzr
    @Artemzr
    Хорошо, выложу вам кусок своего кода, опять же, это не полностью вся программа, а именно тот кусок где я использую QStackedWidget.

    MainWidget::MainWidget(QWidget *parent = 0) : QWidget(parent)
    {
       // Виджет для упражнения "мозаика".
      mosaicWidget = new MosaicWidget(this); 
       // Виджет для упражнения "карточка".
       cardWidget = new CardWidget(this);
       // Виджет для упражнения "написание".
       cardWidget = new CardWidget(this);
       
       // Соединяем сигнал окончания упражнения со слотом настройки следующего виджета
       connect(mosaicWidget, SIGNAL(finished()), this, SLOT(setupNextLesson()));
       stackedWidget->addWidget(mosaicWidget);
       .. // Аналогично для всех остальных
    }
       
    MainWidget::setupNextLesson()
    { 
         // Получаем случайный индекс от 0 до 2
         int randomIndex = qrand() % 3;
         // Настраиваем определенный виджет для показ
         switch(randomIndex)
         0 : mosaicWidget->setup(); break();
         1 : cardWidget->setup(); break();
         2 : writeWidget->setup(); break();
           
         // Непосредственно активируем нужный на виджет
         stackedWidget->setCurrentIndex(randomIndex);
         updateStatusBar(); 
    }
    

    p.s. Пример я изменил для простоты, в реале все мои виджеты наследуются от одного абстрактного класса, в который вынесены общие методы, в итоге код становился меньше и читабельней.
    Ответ написан