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

Навигация по основам Linux от основателя Gentoo:

Часть I: 1, 2, 3, 4

Часть II: 1, 2, 3, 4, 5

Часть III

1. Документация (вступление)
2. Модель прав доступа
3. Управление аккаунтами
4. Настройка окружения (итоги и ссылки)

Предисловие

Об этом руководстве

Добро пожаловать в первую из четырех частей обучающего руководства по основам Linux, разработанного чтобы подготовить вас к сдаче экзамена Linux Professional Institute 101. В нем вы познакомитесь с bash (стандартной оболочкой командного интерпретатора в Linux), узнаете о большинстве возможностей таких стандартных команд Linux, как ls, cp и mv, разберетесь в инодах, жестких и символьных ссылках, и многом другом. К концу этого руководства у вас сформируется некий фундамент знаний, и вы будете готовы к изучению основ администрирования Linux. К концу всего курса (8 частей), у вас будет достаточно навыков, чтобы стать системным администратором Linux и пройти сертификацию LPIC Level 1 от Linux Professional Institute, если конечно захотите.

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

Опять на собеседованиях по Java спрашивают про hashCode и equals? А кто из собеседующих сам ответит на вопрос, как вычисляется Object.hashCode() и System.identityHashCode()? Насколько дорог вызов этих методов? Как их можно ускорить в HotSpot JVM? Держу пари, едва ли кто даст правильный ответ. Разве что, кто прочитает эту статью.

Эту книгу я перечитывал много раз, и в переводе, и в оригинале. Настолько много, что, рассказывая о ней, чувствую себя немного странно. Примерно как Капитан Очевидность, который вдруг осознал, что он Капитан.

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

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

Трудно научить криптографической безопасности даже умного человека. Особенно умного.

Названный одним из характерных представителей стиля «киберпанк», Нил Стивенсон в «Криптономиконе» возвращается к реальности дня сегодняшнего и даже уходит в прошлое (вплоть до древних греков), в попытке оценить роль «технарей» в современном обществе. Книга была опубликована в 1999 году, и 17 лет назад казалось, что автор испытывает чрезмерный оптимизм по поводу влияния компьютеров и интернета на человечество, рисует реалистичную, но в чем-то утопию. Сейчас так уже не кажется. Милые артефакты 20-го века вроде Windows NT и BeOS совершенно не мешают актуальности вселенной «Криптономикона». Технологии ушли вперед, но люди… Люди почти не изменились, как в хорошем смысле, так и в плохом.

Книжнообзорный этикет требует от меня предупредить читателя о спойлерах, хотя на самом деле их тут почти нет. Любая попытка втиснуть 900-страничный том, в котором две основные сюжетные линии и десяток побочных, в несколько страниц отзыва, к счастью, обречена на провал. Вместо спойлеров попробую оценить, насколько заложенные в книгу технические и социальные околокомпьютерные идеи реализовались на практике.

В предыдущих статьях мы рассмотрели процесс разработки PostgreSQL, а также примеры некоторых реальных патчей, принятых в эту РСУБД за последнее время. При этом рассмотренные патчи были, прямо скажем, какие-то «несерьезные» — исправление опечаток, исправление простейших косяков, найденных при помощи статического анализа, и прочее в таком духе.

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

Если эта тема вам интересна, прошу под кат.

Функцией партиционирования таблиц в PostgreSQL, к сожалению, активно пользуются пока не многие. На мой взгляд, очень достойно о ней рассказывает в своей работе Hubert Lubaczewski (depesz.com). Предлагаю вам еще один перевод его статьи!

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

Так что я постараюсь объяснить в меру своих знаний и возможностей, что это такое, зачем его стоит использовать и как это сделать.

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

Аргументы за Scala известны:

1. Scala лаконичная;
2. Scala функциональная;
3. Scala крутая и современная;

В ответ на то, что Scala медленно загибается, Мартин Одерски заявил следующее: «В 2015-м было затишье, но вот в 2016-м развитие Scala должно ускориться».

В этом посте я не буду глубоко погружаться в техническую дискуссию, есть множество специалистов, которые сделают это лучше меня. Сегодня мы поговорим о том, нужна ли Scala разработчику для саморазвития, для этого хочу предложить вам перевод статьи Matthew Casperson.

Ну и в конце дам пару ссылок на популярные статьи по теме за последние несколько лет, если вдруг вы какие-то из них пропустили.

Здравствуйте, дорогие читатели. Мы редко пишем о книжных «долгостроях», то есть, о работах, которые никак не выйдут на Западе. Но сегодня хотим познакомить вас с постом из блога Мартина Клеппмана, который уже не первый год трудится над фундаментальной книгой "Designing Data-Intensive Applications"

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

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

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

Я разрабатываю бесплатную библиотеку StreamEx, которая расширяет стандартное Java 8 Stream API, добавляя туда новые операции, коллекторы и источники стримов. Обычно я не добавляю всё подряд, а всесторонне рассматриваю каждую потенциальную фичу. Например, при добавлении новой промежуточной (intermediate) операции встают такие вопросы:

1. Будет ли она действительно промежуточной, то есть не будет трогать источник до выполнения терминальной операции?
2. Будет ли она ленивой и вытаскивать из источника не больше данных, чем требуется?
3. Сработает ли она на бесконечном стриме? Требует ли она ограниченный объём памяти?
4. Будет ли она хорошо параллелиться?

Минусик по любому из этих пунктов заставляет серьёзно задуматься, добавлять ли такую операцию. Минусик по первому — это сразу нет. Например, у конкурентов в jOOλ есть операция shuffle(), которая выглядит как промежуточная, но на самом деле прямо сразу потребляет весь стрим в список, перемешивает его и создаёт новый стрим. Я такое не уважаю.

Минусики по остальными пунктам не означают сразу нет, потому что есть и стандартные операции, которые их нарушают. Второй пункт нарушает flatMap(), третий — sorted(), четвёртый — всякие limit() и takeWhile() (в JDK-9). Но всё-таки я стараюсь этого избегать. Однако на днях я открыл для себя операцию, которая плохо параллелится и в зависимости от использования может не сработать на бесконечном стриме, но всё же слишком хороша. Через неё удаётся буквально в несколько строчек выразить как практически любую существующую промежуточную операцию, так и кучу несуществующих. Я назвал операцию headTail().

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

От переводчика: перед вами краткий обзор протокола HTTP и его истории — от версии 0.9 к версии 2.

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

В этой статье мы обсудим, что такое HTTP, и как он стал именно таким, каким мы видим его сегодня.

В этой статье я хотел бы рассказать о том, как выглядит процесс разработки PostgreSQL глазами одного из контрибьютеров в этот самый PostgreSQL. Заниматься разработкой этой СУБД я начал в декабре 2015 года, когда устроился работать в компанию Postgres Professional. То есть, не так уж давно. А значит, еще свежи воспоминания о моментах, которые поначалу казались мне не вполне очевидными. Хотелось бы их законспектировать, чтобы новым людям, приходящим в нашу команду, а также всем тем, кто желает попробовать себя в роли разработчика открытой реляционной СУБД, было легче. Я расскажу о том, как выглядит процесс разработки PostgreSQL, какие инструменты я использую в своей повседневной работе, как следует оформлять патчи, и так далее. Заинтересовавшихся прошу проследовать под кат.

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



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

При разработке каких-либо продуктов у команды зачастую возникает желание перестать бороться с текущим состоянием проекта и переписать всё снова, на этот раз "правильно" и "по науке". Обычно такие порывы не одобряются, но в этот раз я бы хотел предложить к прочтению перевод поста Hugo Baraúna, посвященного тому, какие вопросы нужно задать себе, если всё же решили переписывать.

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

Будут ли обе платформы существовать одновременно, или нет?

Недавно Лукас Эдер заинтересовался в своём блоге, способен ли JIT-компилятор Java оптимизировать такой код, чтобы убрать ненужный обход списка из одного элемента:

// ... а тут мы "знаем", что список содержит только одно значение
for (Object object : Collections.singletonList("abc")) {
    doSomethingWith(object);
}

Вот мой ответ: JIT может даже больше. Мы будем говорить про HotSpot JVM 64 bit восьмой версии. Давайте рассмотрим вот такой простой метод, который считает суммарную длину строк из переданного списка:

static int testIterator(List<String> list) {
    int sum = 0;
    for (String s : list) {
        sum += s.length();
    }
    return sum;
}

Шесть месяцев назад ребром встал вопрос о тексте для моего дипломного перевода. Результатом помощи коллективного разума стало решение переводить главу Scalable Web Architecture and Distributed Systems за авторством Kate Matsudaira. Нужно отметить, что это мой первый перевод такого объема и сложности. Текст, был мною относительно успешно переведен, хотя по качеству перевода я поставил бы себе 6-7 из 10. Дабы мои усилия не пропали втуне, публикую результат своих трудов.

По просьбам читателей Хабра, теперь полная версия в виде топика.

Масштабируемая веб-архитектура и распределенные системы

Кейт Матсудейра

Перевод: jedi-to-be.
Коррекция: Anastasiaf15, sunshine_lass, Amaliya, fireball, Goudron.

Взявшись за написание небольшого, но реального и растущего проекта, мы «на собственной шкуре» убедились, насколько важно то, чтобы программа не только хорошо работала, но и была хорошо организована. Не верьте, что продуманная архитектура нужна только большим проектам (просто для больших проектов «смертельность» отсутствия архитектуры очевидна). Сложность, как правило, растет гораздо быстрее размеров программы. И если не позаботиться об этом заранее, то довольно быстро наступает момент, когда ты перестаешь ее контролировать. Правильная архитектура экономит очень много сил, времени и денег. А нередко вообще определяет то, выживет ваш проект или нет. И даже если речь идет всего лишь о «построении табуретки» все равно вначале очень полезно ее спроектировать.

К моему удивлению оказалось, что на вроде бы актуальный вопрос: «Как построить хорошую/красивую архитектуру ПО?» — не так легко найти ответ. Не смотря на то, что есть много книг и статей, посвященных и шаблонам проектирования и принципам проектирования, например, принципам SOLID (кратко описаны тут, подробно и с примерами можно посмотреть тут, тут и тут) и тому, как правильно оформлять код, все равно оставалось чувство, что чего-то важного не хватает. Это было похоже на то, как если бы вам дали множество замечательных и полезных инструментов, но забыли главное — объяснить, а как же «проектировать табуретку».

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

Данная статья является попыткой ответить на эти вопросы хотя бы в первом приближении.

«Только со смертью догмы начинается наука.»
// Галилео Галилей

«Я начал завидовать рабам. Они всё знают заранее. У них твёрдые убеждения.»
// х/ф Марка Захарова «Убить дракона» по мотивам пьесы Евгения Шварца

Уже пару лет и дня не проходит, чтобы я не услышал (или не прочитал) от людей, начинающих новые проекты, фразу типа «Возьмем серверный движок для REST API и MVC, и погнали». Сначала я думал, что у этих слов есть один источник, может книжку какую завезли во все магазины или где-то в топе поисковиков лежит статья, зомбирующая разработчиков. Если же выяснять у них, что они понимают под REST и MVC, то можно повредиться умом. Ну с MVC уже все ясно, об этом я уже давно писал, ничего не изменилось, только усугубилось, стоит набрать в Google Images «mvc» и мы увидим страшное, стрелочки в любые стороны. Ну а про REST отвечают следующее: ну как же, нам нужно из браузерного GUI и мобильного приложения вызывать серверные методы, например: setUserCity(userId, cityId) или calculateMatrix(data) или startVideoConverter(options, source, destination) а потом мы столкнемся с большой нагрузкой и архитектура REST все решит. Дальше я задаю вопросы, от которых глаза округляются уже у тех, кто недавно еще горел праведной верой, рвался в бой и точно знал, что к чему в этом мире. Теперь можно перейти к рассмотрению терминологической катастрофы, в эпицентре которой мы с вами пребываем.