Крис Касперски на RSA Conference 2015. Источник: хакер.ру

Говорят, что незаменимых людей нет. По большей части это действительно так, но есть и исключения. Например, если говорить о Николае Лихачеве, которого весь мир знает, как Криса Касперски, то здесь утверждение о незаменимости дает сбой. В ИТ-сфере этот человек сделал очень многое, о чем можно судить хотя бы по печатному «наследию»: Касперски оставил после себя больше 20 книг и 500 статей. Он был настоящим хакером, в изначальном понимании этого слова. То есть человеком, который прекрасно разбирался в том, как и что работает в ИТ.

Собственно, информационными технологиями он стал заниматься очень рано — с начальных классов, сразу после появления первого компьютера, который носил гордое название «Правец 8Д». По сути, это клон британского компьютера Oric Atmos, причем инструкция была на болгарском языке. Тем не менее, Крис (тогда еще Николай) быстро со всем освоился, написав свою первую игру. В ней пользователь должен был поймать рыбку. Графики здесь не было, ее роль играли символы. В центре экрана находился рыбак в виде знака вопроса, а рыбка отображалась при помощи нолика и знака «больше». Ловить рыбу нужно было, нажимая на пробел.

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

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

Один из таких мифов – что в городах отвратительный воздух, грязный и ядовитый. И вместо кислорода сплошные выхлопы от автомобилей. Мы воспринимаем это как данность, и не пытаемся исправить ситуацию, даже там, где способны это сделать, в собственном доме, или офисе. Даже те, у кого есть маленькие дети, или проблемы с аллергией, прикладывают свои усилия в слепую, не контролируя результатов.

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

Но этого недостаточно. Нужен прибор которым вы могли-бы непосредственно померять качество воздуха в вашем доме. Что бы Вам было понятно и очевидно чем Вы дышите. Как температура на градуснике.

Речь пойдёт о программах и библиотеках для UNIX-подобных систем, распространяемых в виде исходного кода (в том числе в виде тарболлов), написанных обычно на C и C++ (хотя этот же порядок работы может применяться к софту на любом языке). Многие вещи в этой статье написаны применительно конкретно к GNU/Linux, хотя многое из статьи может быть обобщено и на другие UNIX-подобные ОС.

Под словом «пакет» я понимаю в этой статье пакет с исходными текстами, причём не пакет конкретного дистрибутива GNU/Linux, а просто пакет, исходящий от оригинальных авторов софта (UPD от 2017-02-09: кроме тех случаев, где из контекста ясно, что слово «пакет» употреблено в другом смысле).

В этой статье я разберу следующие вопросы:

• Вот скачал программу или библиотеку. Как её собрать и установить? Как воспользоваться библиотекой?
• Что такое префикс (prefix) установки? В чём разница между сборкой и установкой? Куда обычно устанавливают программы?

Я разберу только совсем базовые вещи. Те, которые типичные участники сообщества свободного ПО, программирующие на C и C++ под UNIX-подобные системы, обычно уже знают. Как создавать тарболлы (на примере «голого» make) и как устанавливать чужие тарболлы. Advanced советы по созданию «хороших» пакетов я не дам. «Продвинутые» вещи читайте в документации систем сборки, в замечательной статье «Upstream guide» от Debian (в её конце есть ещё куча ссылок о создании «хороших» пакетов). Многое в этой статье можно было сделать по-другому, моя цель: дать хотя бы один способ, не пытаться объять необъятное.

Ребята, свершилось! После долгих шести недель ожидания наконец вышла версия Rust 1.15 с блекджеком и процедурными макросами.

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

А что же это дает простым смертным? Практически бесплатную [де]сериализацию, удобный интерфейс к БД, интуитивный веб фреймворк, выводимые конструкторы и много чего еще.

Да, если вы все еще не добрались до этого языка, то сейчас самое время попробовать, тем более, что теперь установить компилятор и окружение можно одной командой:

curl https://sh.rustup.rs -sSf | sh

Впрочем, обо всем по порядку.

Хочу поделиться историей, ну и заодно услышать мнения других участников хабрасообщества. Это небольшая история о том, как агрессивное внедрение методологии разработки Agile (Scrum) в отдельно взятой российской IT компании послужило началом исхода из компании лучших разработчиков. Обычно в статьях про Agile рассказывают, какая это классная и полезная методология, и вообще — это лучшее, что было придумано в этом направлении. Возможно, эта статья поможет взглянуть на Agile с другой стороны, ведь у любой монеты, как оказалось, есть две стороны.

В общем, в 2010-м году была основана одна российская компания (что-за компания конкретизировать смысла нет), работала она в сфере IT-разработки (ПО для банковских продуктов).

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

Нижележащий текст преследует несколько целей:

1. Дать краткий обзор (читай — немного погундеть на тему) неудовлетворительного состояния инструментария, применимого к хтоническим чудовищам мира C/C++;
2. Предложить своё альтернативное решение (бесплатно-без-СМС-и-регистрации — проект некоммерческий и выложен на GitHub под MIT-лицензией);
3. Призвать сообщество пообщаться на тему и собрать идеи;
4. Пригласить присоединиться к разработке проекта на GitHub.

Сразу оговорюсь, что хотя проект создавался в первую очередь как альтернатива, а точнее, дополнение Doxygen для сишных и плюсовых API, архитектурно он в равной степени пригоден и для других языков. Это позволяет создавать порталы документации разноплановых библиотек — сами библиотеки могут быть написаны на разных языках, а в документации будет единство стиля во внешнем виде и поведении.

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

Для тех, кто не уследил — его в начале 2012 пролоббировали и с энтузиазмом начали внедрять программисты в Селектеле. Тогда же я обещал опубликовать отчёт о том, насколько «это всё» можно использовать.

Продакт в коммерческом проекте — это не в маленькая песочница «для себя», не академический эксперимент в области Computer Science. Это бесконечная борьба за «линию партии», когда вокруг ад, ужас и погибель, а оно всё равно должно работать. Int64 в XML-RPC кодируется строкой (потому что int'ы в XML-RPC signed int32), openssl при чтении нескольких сертификатов из файла читает только первый из них, в bool надо писать либо «1», либо «0», но иногда — «2», ибо только так придумали закодировать третий режим — и т.д. и т.п. В этих условиях требования к языку постепенно перерастают в требования к его экосистеме, инфраструктуре, готовности адаптироваться к реальному миру.

Я буду писать о Haskell с позиций product owner'а, менджера проекта, системного администратора, но никак не программиста. Так что не ожидайте от меня задушевных восторгов о том, как изящно через монадки можно сделать семигрупоид и как здорово выводить типы через типы с помощью типов.

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

Начнём с потребительских свойств.

Примечание от переводчика:

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

---

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

За последние несколько лет стало ощущаться, как качество программного обеспечения и услуг по всей отрасли стало падать, а не расти. Все и всегда находится в стадии Беты (как исходя из названия, так и из качества). Товары отправляются потребителям тогда, когда этого хотят маркетологи, а не когда они реально готовы к продаже, а все потому, что «мы всегда сможем легко все пофиксить». Конечный потребитель превратился из покупателя в бета-тестера, но это уже норма, потому что в разработке используется Agile. В программировании мы стали считать, что ошибки и неудачи — это нормально, поэтому нам теперь не нужно прикладывать так много усилий для их избежания. Поддержка миллионов клиентов — вещь сложная, поэтому волноваться не стоит. Зачем вообще тратить время на ознакомление с фидбеком и репортами от пользователей, если их просто можно отправить в бесконечный лабиринт под названием «саппорт» и «обратная связь»?

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

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

Как сказал один из пользователей StackOverflow, «using SO is like doing lookups with a hashtable instead of a linked list». Мы снова обращаемся к этому замечательному ресурсу, на котором попадаются чрезвычайно подробные и понятные ответы на самые различные вопросы.

В этот раз мы обсудим, что такое метаклассы, как, где и зачем их использовать, а также почему обычно этого делать не стоит.

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

Я не могу безболезненно сидеть за столом дольше часа подряд, и я не могу работать больше, чем стандартный восьмичасовой день. Проблема в том, что последние 15 лет моя стратегия работы заключалась в том, чтобы поймать «поток» и после этого кодить очень долго без перерывов. Эта стратегия очень популярна у кодеров, любящих запираться на сутки, надевать наушники и отключаться от внешнего мира — и именно поэтому они так болезненно реагируют, когда их отвлекают. Программирование требует концентрации, а концентрация работает по принципу клапанного механизма — на разогрев и запуск требуется время, поэтому уже запущенный механизм лучше не останавливать.

Я не думал, что существуют другие способы программирования, и уже начал было смиряться с тем, что обречен на низкую производительность. Но за последние 6 месяцев я обнаружил, что «медленный разогрев и долгая работа без перерывов» — поведение приобретенное, а не врожденное, и вполне возможно переучиться на другие ритмы активности. Это похоже на многофазный сон — как только вы привыкли делать вещи определенным образом, любые изменения очень трудоемки, но возможны — при наличии достаточной мотивации и времени на привыкание.

Когда вышла версия 1.0 Redux, я решил потратить немного времени на серию рассказов о моем опыте работы с ним. Недавно я должен был выбрать “реализацию Flux” для клиентского приложения и до сих пор с удовольствием работаю с Redux.

Почему Redux?

Redux позиционирует себя как предсказуемый контейнер состояния (state) для JavaScript приложений. Редакс вдохновлен Flux и Elm. Если вы раньше использовали Flux, я советую прочитать, что Redux имеет с ним общего в разделе "Предшественники" новой (отличной!) документации.

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

Скриншот изображения на новом СE V с использованием DX 12

В этот вторник, 15 марта, компания Crytek анонсировала выход своего нового движка CryEngine V, который будет распространяться бесплатно. Воспользоваться новой разработкой компании сможет каждый пользователей без каких-либо ограничений, в том числе разработчики получат доступ к исходному коду движка.

Среди основных нововведений:

• Поддержка C#;
• Поддержка DirectX 12;
• Продвинутая волюметрическая система, адаптированная для работы над VR-проектами, которая позволит оптимизировать 3D-рендеринг и минимизировать просадки в производительности;
• Новая система частиц, которая позволяет сфокусировать всю нагрузку при рендеренге в режиме реального времени на GPU;
• Новый лаунчер и переработанный UI;
• Поддержка FMOD Studio;
• Выделенный канал CRYENGINE Q&A для общения разработчиков.

На прошлой неделе многие СМИ писали о чудесных инициативах Microsoft в области открытого программного обеспечения — анонсе SQL Server под Linux, выпуске ОС для сетевых устройств на базе Debian (на самом деле это повтор старых новостей), вступлении в Eclipse Foundation.

Случайно или нет, но эти события затмили собой и оставили без внимания другие инициативы Microsoft, которые совсем не выглядят такими очаровательными. Это соглашение с Acer на предустановку программ Microsoft под угрозой патентного иска, а также попытка запатентовать технологию, которая уже реализована в Ubuntu. «Microsoft любит Linux настолько сильно, что задушит до смерти патентыми исками, в то время как медиа не обращают внимания, а вместо этого рассказывают, что Microsoft теперь "дружит" с GNU/Linux», — комментирует ситуацию TechRights.

Привет, Хаброжители! Мы начали издавать новую серию книг «Pop Science», обзор которых мы сделали на Geektimes.
Здесь мы представим отрывок из книги:

Парадокс Ферми можно сформулировать так.

Поскольку Вселенная настолько велика, ее размеры настолько необъятны и в одном только Млечном Пути светят сотни миллиардов звезд, многие из которых имеют вокруг себя планетар-ные системы, то в случае, если Земля не является в высшей степени нетипичным местом в том, что касается условий для развития жизни, Вселенная должна кишеть такими планетами, в том числе населенными разумными цивилизациями. Многие из них должны иметь технологии, позво-ляющие путешествовать в космосе, и к настоящему моменту они уже должны были посетить нас.
Где же они все в таком случае?

Уважаемые хабравчане.

Поскольку дискуссия вокруг статьи идет весьма активно, Жан-Жак Дюбре (он читает комментарии) решил организовать чаты в gitter.

Вы можете пообщаться с ним лично в следующих чатах:
https://gitter.im/jdubray/sam
https://gitter.im/jdubray/sam-examples
https://gitter.im/jdubray/sam-architecture

Также автор статьи разместил примеры кода здесь: https://bitbucket.org/snippets/jdubray/

По поводу кода он оставил следующий комментарий:

I don't code for a living, so I am not the best developer, but people can get a sense of how the pattern works and that you can do the exact same thing as React + Redux + Relay with plain JavaScript functions, no need for all these bloated library (and of course you don't need GraphQL).

pro-cras-ti-na-tion |prəˌkrastəˈnāSHən, prō-|
существительное
задержка или откладывание чего-либо: первый совет — избегайте прокрастинации.

Кто бы мог подумать, что после десятилетий борьбы с прокрастинацией словари будут содержать решение проблемы.

Избегать прокрастинации. Так элегантно в своей простоте…

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

Нет, «избегайте прокрастинации» — хороший совет только для не настоящих прокрастинаторов. Для тех, кто говорит «Я захожу на Facebook несколько раз в день на работе. Я такой прокрастинатор!». Это те люди, которые будут говорить настоящему прокрастинатору «Не откладывай дела на потом и у тебя все будет хорошо».

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

Администрация RuTracker сделала логичный шаг в ответ на блокировку сайта на территории Российской Федерации.

На форуме опубликовано такое сообщение:

«Уважаемые пользователи!

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

Но сегодняшний день поставил точку в этих соглашениях, т.к. пользователям из РФ заблокировали доступ к нашему трекеру. Следовательно правообладатели не захотели продолжать сотрудничество, что позволяет и нам более не придерживаться его.

Посему больше не стоит переживать из-за своих релизов, которые могут быть закрыты ПО. Смело делитесь!»

А что бы вы сделали?

Вот что бы вы сделали, если бы вам гарантировали выплату $1000 в месяц до конца вашей жизни? И да, именно такую сумму, скорее всего, будут выплачивать – по крайней мере тут, в США. Представьте себе это на минутку, не думая о том, что бы сделали другие – подумайте, что бы сделали лично вы. Возможно, вы бы больше занимались тем, что вам нравится? Чем именно?

Но разве это уже не пробовали в России?

Если вы сравниваете эту идею с коммунизмом, давайте подумаем. Давайте рассмотрим, что реально делали в СССР, а чего не собирались делать. Что на самом деле там было – это передача средств производства от тех, кто управляет делами на основе рыночных сил, в руки бюрократов, принимавших решения на основании политики и кумовства. Это ужасная идея. Но почему?

Рынок работает потому, что он может понять, что нужно людям, насколько это нужно, и у него есть возможность доставки этого людям. Рассмотрим, к примеру, хлеб. В СССР считалось, что хлеб нужен всем. Это решение принималось властями, они старались претворить его в жизнь — нужен был на самом деле этот хлеб всем и каждому, или нет. Работало это не очень хорошо, и иногда случались нехватки. К тому же, люди со связями получали больше, а иные – ничего не получали. Попытка дать хлеба всем, пусть и благородная, провалилась.

Магия рынков

Как это происходит в США? Одни люди делают хлеб и продают его в магазины, чтобы другие люди с деньгами могли купить хлеб. Если его не раскупают, то производится меньше хлеба. Если раскупают весь, производится больше хлеба. Производители хлеба принимают решение о производстве хлеба не в директивном порядке – они прислушиваются к рыночным силам, которые влияют на принятие решений снизу вверх. Получается, что изготавливается как раз нужное количество хлеба по нужной цене. Идеально? Нет. Почему, и как это улучшить?

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

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

22 июля этого года в Российской Газете опубликован проект приказа «Об утверждении минимальных ставок вознаграждения, а также порядка сбора, распределения и выплаты вознаграждения за отдельные виды использования произведений и фонограмм, опубликованных в коммерческих целях».

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