На этот пост меня подтолкнула публикация «Почему я ворую книги, бедные авторы, и как это исправить», а именно — скепсис и возражения на мой комментарий о том, что я не читаю плохие книги. Мне предложили рассказать, как я выбираю книги для чтения и что именно читаю. Ну я и повелся.
Оформить список было сравнительно просто, FBReader любезно хранил на GoogleDrive все скачанные книги с того момента, как там появилась эта услуга. Предлагаю вашему вниманию список прочитанного мной за 2,5 года из жанров фентези и фантастики.

Написано довольно много статей о Kotlin, но об его использовании в реальных проектах – единицы. В особенности, Kotlin часто хвалят, поэтому я буду говорить о проблемах.

Сразу оговорюсь: я ничуть не жалею об использовании Kotlin и всем его рекомендую. Однако хочется предупредить о некоторых подводных камнях.

Наша компания занимается администрированием веб-серверов на базе CentOS. Довольно часто наши клиенты используют веб-приложения на базе python, ruby или java. Для автозапуска подобных приложений есть готовые шаблоны для написания стартап-скриптов. Но прогресс не стоит на месте, вышел уже второй релиз CentOS 7 и, следуя старой традиции «не ставить dot-zero релизы на продакшен», мы начинаем предлагать клиентам сервера на базе CentOS 7.1 (1503).

В CentOS7, так же как и в его родителе RHEL7, используется systemd — менеджер системы и служб для Linux, совместимый со скриптами инициализации SysV и LSB. systemd обеспечивает возможности агрессивной параллелизации и много всего прочего.



Огромный монстр с множеством возможностей, гибкими настройками и мегабайтами документации…

Но что делать, если стоит задача быстро-быстро, вот прямо вчера, сделать автозапуск некоего сервиса?
Давайте выжмем из документации минимально необходимый набор информации для создания простых старт-стоп скриптов.

Содержание

• Вопросы и ответы
  
• Введение
  
  • Пре-реквизиты
    
  • Настройка компьютера
    
  
  
• 1.0 Играем с Busybox
  
  • 1.1 Docker Run
    
  • 1.2 Терминология
    
  
  
• 2.0 Веб-приложения и Докер
  
  • 2.1 Статические сайты
    
  • 2.2 Образы
    
  • 2.3 Наш первый образ
    
  • 2.4 Dockerfile
    
  • 2.5 Docker на AWS
    
  
  
• 3.0 Многоконтейнерные окружения
  
  • 3.1 SF Food Trucks
    
  • 3.2 Сети Docker
    
  • 3.3 Docker Compose
    
  • 3.4 AWS Elastic Container Service
    
  
  
• 4.0 Заключение
  
  • 4.1 Следующие шаги
    
  • 4.2 Фидбек автору
    

Вопросы и ответы

Что такое Докер?

Определение Докера в Википедии звучит так:

программное обеспечение для автоматизации развёртывания и управления приложениями в среде виртуализации на уровне операционной системы; позволяет «упаковать» приложение со всем его окружением и зависимостями в контейнер, а также предоставляет среду по управлению контейнерами.

Ого! Как много информации.

Github — важная часть жизни современного разработчика: он стал стандартом для размещения opensource-проектов. В «2ГИС» мы используем гитхаб для разработки проектов web-отдела и хостинга проектов с открытым кодом.

Хотя большинство из нас пользуются сервисом практически каждый день, не все знают, что у него есть много фишек, помогающих облегчить работу или рутинные операции. Например, получение публичного ключа из URL; отслеживание того, с каких сайтов пользователи приходят в репозиторий; правильный шаринг ссылок на файлы, которые живут в репозиториях гитхаба; горячие клавиши и тому подобное. Цель этой статьи — рассказать о неочевидных вещах и вообще о том, что сделает вашу работу с гитхабом продуктивнее и веселее (я не буду рассматривать здесь работу с API гитхаба, так как эта тема заслуживает отдельной статьи).

Содержание

• Трюки с URL
• Горячие клавиши
• Тикеты и пулл-реквесты
• Github markdown
• Аккаунт
• Работа с репозиториями
• Поиск кода
• Командная строка и Github
• User scripts
• Github-вандализм
• Дополнительные Github-ресурсы
• Полезные ссылки

В моем случае, в качестве frontend сервера, стоит nginx и формат access-лога имеет вид:

log_format main '$remote_addr — $remote_user [$time_local] "$host" "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for" -> $upstream_response_time';

Что на выходе дает что-то вроде такой строки:

188.142.8.61 — - [14/Sep/2014:22:51:03 +0400] «www.mysite.ru» «GET / HTTP/1.1» 200 519 «6wwro6rq35muk.ru» «Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.191602; .NET CLR 3.5.191602; .NET CLR 3.0.191602» "-" -> 0.003

1. tail -f /var/log/nginx/nginx.access.log | cut -d ' ' -f 1 | logtop

Позволяет получить общую картину: распределение уникальных IP, с которых идут запросы, кол-во запросов с одного IP и т.д.
Самое ценное — что все это работает в режиме реального времени и можно мониторить ситуацию, внося какие-либо изменения в конфигурацию (например просто забанить ТОП 20 самых активных IP через iptables или временно ограничить географию запросов в nginx через GeoIP http://nginx.org/ru/docs/http/ngx_http_geoip_module.html).

Предисловие

Некоторые из вас наверняка недавно проходили Stanford'ские курсы, в частности ai-class и ml-class. Однако, одно дело просмотреть несколько видео-лекций, поотвечать на вопросики quiz'ов и написать десяток программ в Matlab/Octave, другое дело начать применять полученные знания на практике. Дабы знания полученые от Andrew Ng не угодили в тот же тёмный угол моего мозга, где заблудились dft, Специальная теория относительности и Уравнение Эйлера Лагранжа, я решил не повторять институтских ошибок и, пока знания ещё свежи в памяти, практиковаться как можно больше.

И тут как раз на наш сайтик приехал DDoS. Отбиваться от которого можно было админско-программерскими (grep / awk / etc) способами или же прибегнуть к использованию технологий машинного обучения.

Далее пойдёт рассказ о создании нейронной сети на Python 2.7 / PyBrain и её применении для защиты от DDoS'а.

Только что я столкнулся с еще одним проявлением синдрома самозванца: «Я правда разработчик — или просто хорошо гуглю?»

Далее следовал ответ, в котором я, однако, не увидел главного — поэтому ответить придется мне: слишком уж многие боятся без каких-либо оснований.

Переведено в Alconost

Если информацию легко найти, это не делает человека глупым

Частенько мне доводится слышать одну историю — полагаю, подлинность ее сомнительна, но, как бы там ни было, суть такова. Когда у Эйнштейна попросили номер телефона, он полез его искать и сказал: «Зачем запоминать то, что можно найти менее чем за две минуты?»

Update статьи “Пиши резюме правильно или “умею улыбаться и пеку оладушки”.

Начну с того, что я IT рекрутер. В этом тексте выражено только мое мнение по вопросу составления резюме. Это вовсе не значит что мои коллеги по отрасли считают также. Возможно, с чем то-то они согласны, с чем-то нет.

Да, каюсь, в первоначальном варианте статьи, опубликованном некоторое время назад, я несколько категорично выразила свое мне о наличии и качестве фотографии в резюме. Давайте поступим так: ставить фотографию или нет — решать вам. По своему опыту могу сказать лишь, что:

1. Работая в IT кадровом агентстве, я общаюсь с кандидатами только по телефону и мне психологически комфортнее представлять себе человека визуально. Возможно вам тоже. Часто процесс трудоустройства растягивается на недели, а то и на месяцы. В этот период я веду с кандидатом переписку, общаюсь по телефону и в скайпе. Волнуюсь за него, особенно если процесс рассмотрения резюме почему-то затягивается, а человеку срочно нужна работа. Если история заканчивается хорошо, и кандидата приглашают в компанию — радуюсь. И так изо дня в день, и из месяца в месяц. Человек становится уже в чем-то близким для меня. И не представляя его визуально — чуть сложнее и как-то грустнее, что ли, работается.

Поэтому фото в резюме важно для меня, как для рекрутера.

2. Для руководителя, ищущего специалиста себе в команду — фото в резюме кандидата может быть важно по другой причине: с этим человеком он и его коллеги будут работать по 8 часов в день 5 дней в неделю. И хочется, чтобы человек вписался в команду. Конечно, понять, впишется специалист в команду, или нет, можно только на собеседовании, и то не всегда. Но всех на собеседование не пригласишь, у руководителя мало времени для этого. Фото в таком случае выступает для него одним из фильтров для экономии времени.

Отталкиваясь от этого, решать, размещать ли фотографию в резюме, и какую именно — вам. Я лишь попробовала объяснить, почему это может быть косвенно полезно при поиске работы.

И напоследок, перед тем как вы начнете, уже наконец, читать саму статью, хочу попросить вас — не стесняйтесь комментировать! Ваше мнение для меня очень важно, потому что вы — мои друзья, или коллеги по отрасли или те, кому я звоню каждый день, говоря: ”здравствуйте, я нашла ваше резюме..."

По долгу службы я каждый день просматриваю HeadHunter, Linkedin и множество других ресурсов для поиска на предмет IT специалистов разного толка.
Находясь по ту сторону HeadHunter’а, не перестаю удивляться изобретательности тех, кто находится в поиске работы.
Предлагаю поговорить о том, как эффективно позиционировать себя на рынке труда.
Правильное продающее резюме это первый и главный шаг к работе мечты.
Рекомендации будут практические, проверенные на собственном опыте как со стороны соискателя, так и со стороны рекрутера.

В предыдущей статье «Медовый месяц менеджера: как его провести с пользой» мы говорили о том как происходит назначение на позицию менеджера и что может делать новый менеджер первые месяцы работы в должности. Давайте продолжим разбираться в этой теме.

Как построить карьеру менеджера проектов?

Нужно ли расти из технического специалиста или целенаправленно, с нуля учиться на менеджера? Смогу ли я управлять коллективом, не умея выполнять задания, которые я даю своим сотрудникам? Что ждет меня через 3-5-7 лет? Что предпринять сейчас, чтобы приблизиться к собственной мечте (и какова вообще она — карьерная мечта руководителя проектов)?

Я больше 10 лет занимаюсь проектным менеджментом и такие вопросы слышу часто (да что там — задаю их и сам себе). Единственно-верных ответов, конечно, не существует, а вот собственными соображениями я поделиться могу.

Сам я давно пришел к убеждению, что ни у специалистов по кадрам, ни у тех, кто занимается проф. ориентацией, нет ответов ни на эти, ни на более конкретные вопросы. Например, «Может ли менеджер проектов перейти из сферы ИТ, скажем, в строительство?».

Мы знаем, примеры есть. Однако, когда и почему такие переходы оказываются успешны — ответить затрудняемся.

Часто работодатели не ограничиваются в вакансии требованиями к знаниям проектного управления и общему стажу, а обязательно требуют релевантный опыт (например — 5 лет в управлении разработкой сайтов или внедрения ERP и т.п.). Сами менеджеры тоже стараются строить карьеру с таким прицелом, чтобы развиваться в наиболее симпатичной области. Но это на уровне интуиции. А можно ли подвести под нее какие-либо правила?

В ноябре 2012 в МГТУ им. Баумана мы, Школа системного анализа,
провели открытое событие «Введение в профессию системного аналитика».

Наконец стала доступна первая часть видео, выступление
Сергея Нужненко на тему «В чём заключается работа системного аналитика»:

1. Мифы о задачах и ответственности. Смежные роли (5 минут): vimeo.com/61652862​

2. Риски и неопределённость. Место и задачи в проектном цикле (18 минут): vimeo.com/61968936

3. Окружение, предмет и модель работы. Типовые процессы (10 минут): vimeo.com/62449309

4. Аналитический цикл работы с информацией. Модальная логика (12 минут): vimeo.com/64330992

Эту статью я хочу посвятить временами нелегкой, но увлекательной профессии ИТ-аналитика. На Хабре не так много материалов по данной дисциплине. К примеру, по управлению проектами – на порядок больше. Но выложенные недавно две статьи (раз и два), похоже, вызвали интерес, посему я тоже хотел бы внести свой скромный вклад. Сам работаю более 8 лет в роли аналитика, так что постараюсь не потратить Ваше время зря.
Не стану пересказывать теорию (ее можно почерпнуть в замечательной книге Вигерса или в BABOK). Мне бы хотелось сосредоточиться на практической стороне вопроса – описать выжимку из «боевого» опыта, как своего, так и некоторых других людей, с которыми мне посчастливилось работать.

Здравствуйте.

Этот топик открывает цикл статей по использованию системы управления конфигурацией Puppet.

Что такое система управления конфигурацией?

Предположим, что у вас есть парк серверов, выполняющих различные задачи. Пока серверов мало и вы не растёте, вы легко настраиваете каждый сервер вручную. Устанавливаете ОС (может быть, автоматизированно), добавляете пользователей, устанавливаете софт, вводя команды в консоль, настраиваете сервисы, правите конфиги ваших любимых текстовых редакторов (nanorc, vimrc), выставляете на них одинаковые настройки DNS-сервера, устанавливаете агент системы мониторинга, настраиваете syslog для централизованного сбора логов… Словом, работы довольно много и она не особенно интересна.

Добрый день, уважаемые читатели.
В сегодняшней статье я покажу основы разбора HTML разметки страниц с помощью библиотеки lxml для Python.
Если вкратце, то lxml это быстрая и гибкая библиотека для обработки разметки XML и HTML на Python. Кроме того, в ней присутствует возможность разложения элементов документа в дерево. В статье я постараюсь показать, насколько просто ее применение на практике.

Примерно два года назад я арендовал у одного немецкого хостера не очень мощный сервер на базе Centos 5.2. На нём живут несколько вебпроектов, приносящих некоторую прибыль, и поэтому, я стараюсь присматривать за ним по мере возможности.
На Centos есть стандартный анализатор логов Logwatch, который запускается ежедневно по крону, анализирует содержимое /var/log, делает сводный отчет и присылает его по электропочте. В один прекрасный день я обнаружил в этом отчете запись:

--------------------- yum Begin ------------------------ 
 
 Packages Installed:
    lzo2 - 2.02-3.el5.rf.i386
    dnstracer - 1.8-1.2.el5.rf.i386
    openvpn - 2.0.9-1.el5.rf.i386

---------------------- yum End -------------------------

В тот момент меня она очень смутила, так как в предыдущий день на сервер я не логинился и тем более ничего не устанавливал. Первое, что пришло в голову — сервер был скомпроментирован. Себя я считал уверенным пользователем Linux, однако я растерялся. Благо в тот момент в icq был мой бывший коллега, лучший системный администратор, которого я знаю, и просто очень хороший человек.
Он помог быстро проверить систему. В результате у меня сформировалось краткое HowTo о том, как быстро проверить свой сервер на предмет взлома. Уверен, что многим Храброчитателям оно будет полезно. Предполагается, что пользователь знаком с консолью Linux/Unix.

5 ноября 2013 года к Марсу стартовала ракета. Это была первая межпланетная миссия Индии, "Мангальян", и она отличалась большим риском. Только 40% всех отправленных крупными организациями миссий к Марсу – США, Россия, Япония, Китай – увенчались успехом. Ни одна из космических организаций не сумела достичь успеха с первого раза [тут автор ошиблась: ЕКА успешно отправило миссию "Марс-экспресс" с помощью российских ракет в 2003 году – прим. перев.]. Индийская организация космических исследований ISRO не могла похвастаться большим бюджетом: марсианский зонд НАСА Maven стоил $651 млн, а бюджет индийской миссии составлял $74 миллиона. Для сравнения, бюджет фильма "Марсианин" составил $108 млн. Кроме того, ISRO отправила свою ракету всего через 18 месяцев после начала работ над ней.

После прочтения статьи про любительскую астрономию я загорелся идеей поснимать звезды с помощью обычной камеры без телескопа. Статья подсказала идею про астротрекеры — устройства для компенсации вращения звездного неба на длительных выдержках.



Погуглив, я обнаружил что их легко можно купить. Но вот цена кусалась. Например, самый дешевый Vixin Ploarie Star Tracker стоит от $400 + доставка. Да и грузоподъемность его вызывала сомнения. В перспективе я планировал от широкоугольного объектива перейти и к 70-200/2.8 который вместе с камерой весят под полтора кг.

В процессе поиска оказалось что люди делают себе так называемые Barn Door трекеры: раз, два и другие. Попросту говоря — дверь от сарая. Принцип действия прост — две доски соединенных дверным навесом. Одна из них поворачивается с такой же скоростью как и земля вокруг своей оси. Ось навеса направляетя на Полярную звезду. Нижняя доска ставится на штатив, а на подвижную половинку ставится штативная голова с камерой.

Под катом много картинок.

Чтобы сходу понимать материалы об инфраструктуре открытых ключей, сетевой безопасности и HTTPS, нужно знать основы криптографической теории. Один из самых быстрых способов изучить их — посмотреть или прочитать лекцию Владимира ivlad Иванова. Владимир — известный специалист по сетям и системам их защиты. Он долгое время работал в Яндексе, был одним из руководителей нашего департамента эксплуатации.


Мы впервые публикуем эту лекцию вместе с расшифровкой. Начнём с первой части. Под катом вы найдёте текст и часть слайдов.

Уже второй раз сталкиваюсь с задачей «поставь https на наш сервер» от моего босса, поэтому решил сделать для самого себя шпаргалку, а заодно и для всех остальных. Итак, ситуация следующая: к нам пришел босс и заявил, что ему нужен https. Под катом я напишу 5 простых шагов, как все сделать буквально за час. Приступим.

— Не понимаю, почему люди так восхищаются этим Карузо? Косноязычен, гугнив, поёт — ничего не разберешь!
— А вы слышали, как поёт Карузо?
— Да, мне тут кое-что из его репертуара Рабинович напел по телефону.

Детектив по материалам IT. Часть первая

Я осознаю, что писать очередную статью на тему Модель-Вид-Контроллер это глупо и вредно для «кармы». Однако с этим «паттерном» у меня слишком личные отношения – проваленный проект, полгода жизни и тяжелой работы «в корзину».

Проект мы переписали, уже без MVC, просто руководствуясь принципами – код перестал быть похож на клубок спагетти и сократился наполовину (об этом позже, в обещанной статье про то, как мы применяли «принципы» в своем проекте). Но хотелось понять, что же мы сделали не так, в чем была ошибка? И в течении долгого времени изучалось все, что содержало аббревиатуру MVC. До тех пор пока не встретились исходные работы от создателя – Трюгве Реенскауга…

И тогда все встало на свои места. Оказалось что фактически на основе принципов мы пере-изобретали «original MVC». А то, что зачастую преподносится как MVC, не имеет к нему никакого отношения… впрочем также как и к хорошей архитектуре. И судя по тому сколько людей пишет о несостоятельности «классического MVC», спорит о нем и изобретает его всевозможные модификации, не одни мы столкнулись с этой проблемой.

Более 30 лет собранные в MVC идеи и решения остаются наиболее значимыми для разработки пользовательских интерфейсов. Но как ни странно, несмотря на существующую путаницу и обилие противоречивых трактовок, разработчики продолжают довольствоваться информацией «из вторых рук», черпая знания о MVC из википедии, небольших статей в интернете и фреймворков для разработки веб-приложений. Самые «продвинутые» читают Мартина Фаулера. И почему-то почти никто не обращается к первоисточникам. Вот этот пробел и хотелось бы заполнить. И заодно развеять некоторые мифы.