Часто вспоминается первая работа… Средненький офис, моник 943N и обогреватель Pentium D под ногами. Как возникал из ниоткуда Борис (нет… не Борис «Бритва») с линейкой в руках и настойчиво просил не делать «больно» серверу.

Именно в те далекие времена я впервые познакомился с профайлером. Пользовательские трейсы оказались очень кстати при отладке приложений и поиске медленных запросов. Потом для себя я открыл DMV и XEvents… и профайлером стал пользоваться реже. Причина такого поступка проста – трейсы очень ресурсоемкие.

Однако, данную функциональность не стоит преждевременно придавать анафеме. Начиная с 2005 версии при установке SQL Server по умолчанию создается легковесный системный трейс, который хранит в себе много полезной информации.

Часто при просмотре художественных фильмов о катастрофах на море в голову приходят мысли о том, насколько реально и возможно в жизни все происходящее на экране: могла ли в действительности случиться та или иная ситуация, сработало или не сработало бы то или иное средство спасения, правильно ли повели себя герои фильма и т.д. В этой статье хотелось бы попробовать разобраться, как обстоит дело с безопасностью на море сегодня, и как должны действовать люди в современных реалиях чтобы спастись, на примере ситуаций из достаточно известного художественного фильма, основанного на реальных событиях – «Титаник». Сразу оговорюсь, рассматривать все аспекты я не буду, ввиду их огромного количества. Рассмотрю только самые яркие, глобальные и интересные (разумеется, на мой скромный взгляд).

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

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

Первый: что составляет основное конкурентное преимущество в экономике, которая базируется на глобальных информационных потоках?
Второй: почему высокопрофессиональные специалисты стали мобильнее и всё больше предпочитают независимое дело или свободный график работы?
Третий: как организовывать бизнес-процессы в условиях постоянной инновационной нестабильности, нарастающей специализации и высокого уровня рисковых информационных событий?

Ответы на эти три вопроса показывают, как меняется сама суть менеджмента в условиях информационно-насыщенного пространства.

Интерфейс можно считать своеобразным договором между системой и внешним окружением. В рамках компьютерной программы «система» — рассматриваемая функция или модуль, а «окружение» — весь остальной проект. Интерфейс формально описывает, какие данные могут передаваться между системой и окружением. А «реализацию» можно охарактеризовать как «система минус интерфейс». В языках наподобие Haskell интерфейсы могут быть крайне специфическими. А в языках вроде Python они, напротив, очень обыденны. Выбранный тип интерфейса может повлиять на размер созданного технического долга и производительность программиста. О том, как это посчитать, написано ниже. Также будет предложен метод для оценки и сравнения разных интерфейсов. На основании этих сравнений вы сможете сами понаблюдать за способами использования языка или программного инструмента.

Есть более свежий анонс: https://habrahabr.ru/company/luxoft/blog/280524

Конференция по тестированию программных систем QA: Conference начнется чуть больше чем через месяц и мы готовы рассказать подробнее про нее. Немного статистики:

• 24 полноценных доклада в Москве и Питере
• до 16 докладов — в Новосибирске и Екатеринбурге
• 8 докладов — в Омске
• возможность посмотреть записи всех докладов — всем участникам
• стоимость билета — от 2,000 до 3,000 рублей

Какие темы будут раскрыты:

• Тестирование на сетевое проникновение — от компании PentestIt
• Нагрузочное тестирование
• Автоматизация тестирования (рассматриваются любые аспекты)
• Интеграционное тестирование
• Развертывание различных систем с нуля
• Опыт как положительный, так и отрицательный

Итак, докладчики, о которых мы расскажем сегодня:

• Лука Сафонов и Роман Романов. PentestIt — проникновение в сеть предприятия и про защиту от проникновения.
• Станислав Сидристый — три доклада про все стороны автоматизации в .NET / Java и про стандартизацию подходов к автоматизации
• Галина Галкина — расчет категории риска – подход к управлению регрессионной ТМ
• Александр Акбашев — гоняем тесты на каждый билд: Gerrit, Jenkins, Docker, AWS
• Роман Иовлев — сразу два доклада: «Jedi Power of Model-based testing» и «JDI — Future of UI Automation»
• Игорь Щегловитов — расскажет про автоматизированное тестирование средствами тулсета Microsoft
• Константин Нерадовский — функциональный подход в разработке автотестов на Java

Хотите подробностей? Заходите под кат.

Вступление

Так сложилось, что для ведения проекта не хватало обычного GitHub или GitBucket. Оснавная причина в хранении и контроле версий больших бинанрых файлов psd, 3dsmax и других. На самом деле вариантов решения масса, можно например было использовать Облачный диск или git Large Files System, представленный GitHub. Но взвесив все плюсы и минусы разных подходов к организации, мы пришли к связке GitLab + redmine.

Я не думаю, что есть смысл описывать продукты, я лишь приведу основные достоинства, которые подтолкнули нас на этот выбор.
Основные плюсы GitLab:

• Свой репозиторий.
• Тонкая настройка прав.
• Поддержка git lfs почти из коробки.

Также оба проекта Open Source.

«Продавайте эмоцию, а не товар», «Расскажите про длительный эффект от покупки» – именно эти заголовки в одной из статей испортили однажды мне утро.


Пародия на избыточную эмоциональность в интерфейсах

А началось все с клиента, прочитавшего статью о «правильной» технике продаж и поставившего под сомнение мою компетенцию. Та статья стоила 2-х часового разговора и заставила разложить вопрос эмоциональности в интерфейсах по-полочкам.

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

Обзор практически всех *top утилит под linux (atop, iotop, htop, foobartop и т.д.).

top

Все мы знаем top — самую простую и самую распространённую утилиту из этого списка. Показывает примерно то же, что утилита vmstat, плюс рейтинг процессов по потреблению памяти или процессора. Совсем ничего не знает про загрузку сети или дисков. Позволяет минимальный набор операций с процессом: renice, kill (в смысле отправки сигнала, убийство — частный случай). По имени top суффикс "-top" получили и все остальные подобные утилиты в этом обзоре.

atop

Atop имеет два режима работы — сбор статистики и наблюдение за системой в реальном времени. В режиме сбора статистики atop запускается как демон и раз в N времени (обычно 10 мин) скидывает состояние в двоичный журнал. Потом по этому журналу atop'ом же (ключ -r и имя лог-файла) можно бегать вперёд-назад кнопками T и t, наблюдая показания atop'а с усреднением за 10 минут в любой интересный момент времени.

В отличие от top отлично знает про существование блочных устройств и сетевых интерфейса, способен показывать их загрузку в процентах (на 10G, правда, процентов не получается, но хотя бы показывается количество мегабит).

Незаменимое средство для поиска источников лагов на сервере, так как сохраняет не только статистику загрузки системы, но и показатели каждого процесса — то есть «долистав» до нужного момента времени можно увидеть, кто этот счастливый момент с LA > 30 создал. И что именно было причиной — IO программ, своп (нехватка памяти), процесор или что-то ещё. Помимо большего количества информации ещё способен двумя цветами подсказывать, какие параметры выходят за разумные пределы.

Большинство массовых краж паролей с социальных сетей реализуются при помощи вирусов, которые лезут в hosts и подменяют страничку авторизации, но я недавно открыл для себя ещё более изощрённый метод обмана пользователей:
yandex.ru@%68%61%62%72%61%68%61%62%72%2E%72%75 (сам «трюк» работает не везде, и не везде работает одинаково).

Например, я не всегда бы увидел, что это не адрес поисковой системы, а ссылка на хабр. Фактически мы просто использовали абсолютно правильный формат URL'а (который определён в RFC 1728, см. раздел 3.1):
//<user>:<password>@<host>:<port>/<url-path>
(те. надпись «yandex.ru» выступила в виде логина).

Сам же адрес настоящего логина легко поддаётся кодировке и когда он закодирован в шестнадцатеричном формате, то типичный пользователь вряд-ли будет переводить его в канонический вид. Ещё можно вместо адреса указать IP сервера в нетипичном для глаз виде (уже обсуждалось на хабре) и получить что-то в духе этого:
vkontakte.ru*id@1297618184
И, почему-то, я уверен, что можно подобрать какой-нибудь символ, который внешне будет похожий на знак вопроса…

UPD.: придумать красивый заголовок так и не получилось, писал ночью… =).

Наконец-то разобрался с проблемой, мучавшей меня с самой покупки нового компьютера.
В некоторых играх (Neverwinter nights 1/2; SW: KoToR 1/2; WarCraft 3; Avatar) графика прыгала, будто пропускалась большая часть кадров, в Bully слишком быстро шло время — час игрового времени пролетал за пару секунд (минутная стрелка на часах не доходила даже до 10 минут и время уходило на час вперёд). В 2007-м думал на дрова, их менял, обновлял DirectX — ноль эмоций. В 2008-м думал на Windows, переустанавливал — всё оставалось как прежде. В 2009 на видеокарту, но уже третью поставил, и всё равно результата НОЛЬ, хотя предыдущем компьютере те же самые игры работали нормально (из тех, которые вообще запускались на 256 МБ ОЗУ). Единственный глюк в компьютере кроме прыгающей графики был только в трейсерте и ping.exe — иногда выдавались ненормально большие числа мс (больше миллиарда) и даже отрицательные. Так как пинг, по моему мнению, никак не был связан с графикой, я не считал, что причина глюков в одном и том же месте.

Как вы работаете: по наитию или по науке? Наверное, никто не даст однозначного ответа: работа в ИТ-сфере предполагает сочетание опыта и технологий, точных указаний, норм и красивых, даже талантливых, инженерных находок. В любом случае, опыт решает. А как насчёт чужого опыта? В мире создано множество сводов и правил, предназначенных для работы ИТ-служб, которые объединяет понятие с маркетинговым оттенком — «лучшие практики». Это опыт, сформированный множеством компаний и позволяющий довольно просто решать стандартные проблемы.

В посте мы расскажем, что такое ITIL, ITSM, CobiT, DevOps, как они связаны и почему даже системные администраторы небольших компаний должны что-то знать об этих аббревиатурах.

Привет! А я продолжаю цикл (в блоге замечательного человека Михаила, владельца Текстброкера) про буквы, и что из них можно собрать.

Транзакционные письма — это, грубо говоря, письма-подтверждения, что всё идёт нормально. Например, в двухтысячных у интернет-магазинов было только одно транзакционное письмо: «Ваш заказ подтверждён». После того как Амазон убедительно доказал, что покупателя надо держать в курсе, появилась целая цепочка:
— Да, мы приняли ваш заказ
— Заказ обрабатывается
— Поступила оплата
— Заказ начал собираться на складе
— Товар поехал к вам, будет завтра
— Через час ждите курьера (это обычно SMS, а не email)
— Заказ прибыл, всё хорошо?

Подход к написанию этих писем такой же, как к проектированию UI/UX-моделей. И принципы используются те же самые, что в навигации.

Эта статья родилась из личного опыта. Я искал самые эффективные способы монетизации сайта (ныне уже проданного на Telderi) и в какой-то момент понял, что тема очень обширная и требует подробного исследования. А его результаты могут быть интересны не мне одному.

Рассматриваются способы, наиболее актуальные для России и СНГ и не требующие участия разработчиков или требующие в минимальной степени.

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

Нет в мире такой паховой области, до которой не дотянулась бы рука из города Куробе. А удалось им это посредством компании YKK — крупнейшего в мире производителя застёжек-молний. Компания производит примерно половину всех молний в мире – около 7 миллиардов ежегодно. Но чтобы понять, каким образом эта компания достигла такого успеха, необходимо перенестись назад к самому моменту создания застёжки.

Человечеству надоели пуговицы примерно к середине викторианской эпохи. Булавки, брошки, застёжки и пуговицы – все эти устройства были с нами с древнейших времён. И, наконец, именно тогда они встретили достойного противника. Элиас Хоу, ставший знаменитым благодаря изобретению швейной машины, запатентовал в 1851 году «автоматическую непрерывную одёжную застёжку». Его изобретение было забыто, но всё-таки повлияло на тогдашнее бурное развитие изобретательства.


Элиас Хоу

Распространявшиеся от патента информационные волны в конце 19-го века дошли до чикагского изобретателя Уиткомба Джадсона [Whitcomb Judson]. Он вознамерился избавить человечество от ботинок на кнопках и придумал нечто под названием "застёжки-зажимы". Правда, его изобретение было слишком громоздким, а последовательные его улучшения лишь делали его всё более сложным. Джадсон при помощи спонсора основал компанию Universal Fastener Company (универсальные застёжки). К сожалению, у его устройства был один большой недостаток – оно имело свойство расстёгиваться в самые неподходящие моменты. Самая большая партия была продана партнёрами американской почтовой системе, которая пробовала применить их для мешков с корреспонденцией. Правда, численность той партии была совсем невелика – двадцать штук.

Есть у нас одно .NET-приложение, которое умеет загружать и использовать плагины. Плагины — дело хорошее. Можно функционал расширять, можно оперативненько обновлять их со своего сайта, можно даже юзерам дать SDK и позволить писать свои плагины. Мы всё это и делали. Наши плагины представляли собой обычные .NET-сборки, которые нужно было подкинуть в определённую папку, откуда основное приложения их загружало и использовало. Ну, вы, наверное представляете как — Assembly.Load(), дальше ищем класс, реализующий необходимый интерфейс, создаём объект этого класса и т.д. Всё это работало давно, стабильно и ничто не предвещало беды. Но вдруг в какой-то момент появилась необходимость создать плагин, состоящий из нескольких файлов. В связи с этим было решено считать плагином не просто .NET-сборку (1 файл), а zip-архив, в котором может быть как одна сборка, так и несколько файлов. В связи с этим пришлось научить билд-сервер паковать плагины в архивы, а основное приложение — разархивировать их в нужное место. В общем-то задача на 10 строк кода. Ничто не предвещало беды. И вот скачиваю я с билд-сервера собранный архив с плагином, разархивирую его в нужную папку, запускаю приложение, и… не работает! Стоп, как не работает? Это ведь тот же плагин!

Дальше — больше. Прошу проделать ту же самую процедуру моего коллегу, на его компьютере. Он пробует — и у него всё работает! Но как же так? Одна версия приложения, один и тот же файл с билд-сервера. Какая-то разница в окружении? Сажусь за компьютер коллеги, пробую ещё раз — не работает! Он в этом время пробует на моём — работает! То есть получается, что файл «помнит», кто его разархивировал! Зовём третьего коллегу понаблюдать этот цирк. Последовательно, на одном и том же компьютере, по очереди делаем одни и те же действия: скачиваем архив с плагином, разархивируем в нужную папку, запускаем приложение. Когда это делаю я — программа не видит плагин, когда это делает коллега — всё работает. На третьем круге этих интересных экспериментов вдруг замечаем разницу в действиях: я разархивировал плагин стандартными средствами Windows, а мой коллега — с помощью 7-Zip. И то и другое вызывалось нами из контекстного меню архива, так что разницу в клик по не тому пункту вначале никто не замечал. Ну ок. Получается, файл, извлечённый из zip-архива с помощью 7-zip, отличается от того же файла из того же архива, извлечённого с помощью стандартного архиватора Windows?

Кстати, пока вы не открыли статью под катом, ответьте-ка сами для себя на вопрос, может ли такое быть, что содержимое файлов валидного zip-архива при разархивации 7-zip и через проводник Windows будет разным?

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

От переводчика: я не нашел на хабре подходящего «низкоуровневого сетевого» блога и сначала даже сомневался, стоит ли делать данный перевод. Но всё-таки, все мы с вами разработчики (надеюсь, хотя бы большинство), и описываемая в статье проблема с IPv6 сейчас актуальна, как никогда. До сих пор я вынужден отказываться от любимого русского зеркала Debian (ftp.chg.ru), по причине того, что слишком передовое зеркало отлично работает по IPv6, а мой провайдер выдаёт IPv6 адреса, но IPv6 трафик не роутит, да. В общем, я связался с Оле Якобсеном (Ole J. Jacobsen), главным редактором The Internet Protocol Journal, и с его благословения публикую эту статью. Поехали.

Представляю на ваш суд ещё один перевод коанов о Мастере Фу на русский язык. В данный сборник вошли все коаны, на данный момент опубликованные на сайте Эрика Реймонда. Надо сказать, что сам Эрик личность весьма неординарная, но упоминания в данной статье стоящая. Помимо холиваров в списках рассылки всевозможных проектов за его авторством также несколько серьёзных трудов о Unix — в том числе и о сообществе, без которого экосистема современных открытых проектов не была бы возможной (полный список книг). Идея перевести коаны в очередной раз пришла мне в голову во время чтения одного из таких трудов, а именно «The Art of Unix Programming», поскольку многое из скрытого смысла коанов становится ясно только после прочтения очередной главы оттуда.

Ну и конечно же, дисклеймер: все комментарии и специфика переложения есть плод воображения вашего покорного слуги.
Я публикую этот перевод в надежде на то, что он может кому-то понравиться, но не предоставляю на него никаких гарантий, в том числе соответствия канонам перевода или пригодности для цитирования где бы то ни было.

Безусловно, все те кто общается с ОС Linux хоть раз да имели дело(во всяком случае слышали точно) с командной оболочкой BASH. Но BASH не только командная оболочка, это еще и превосходный скриптовый язык программирования.
Цель этой статьи — познакомить поближе юзеров с bash, рассказать про синтаксис, основные приемы и фишки языка, для того чтобы даже обычный пользователь смог быстренько написать простой скрипт для выполнения ежедневной(-недельной, -месячной) рутинной работы или, скажем, «на коленке» наваять скриптик для бэкапа директории.