Программистика

Полезные инструменты для программиста(разработчика ПО) Инструменты сравнения файлов. Инструмент сравнения, или инструмент diff, — это программа, которая сравнивает две версии текстового файла и определяет, что между ними изменилось. Различия обычно рассчитываются построчно, хотя современные diff-средства могут показывать и диапазон измененных символов на измененной строке. Большинство систем контроля версий поставляются с инструментом сравнения Трехсторонние инструменты слияния. Когда два человека редактируют один и тот же файл, генерируются два независимых набора различий. Инструмент, который может объединить их в окончательную версию файла, содержащую изменения, внесенные обоими участниками, называется инструментом трехстороннего слияния. Название «трехсторонний» обусловлено тем, что задействованы три версии файла: оригинал, версия пользователя A и версия пользователя B. Многие инструменты слияния поставляются со связанным инструментом сравнения. Популярные инструменты слияния — AraxisMerge (www.araxis.com) и WinMerge (winmerge.org). Perforce также поставляется с отличным инструментом трехстороннего слияния Шестнадцатеричные редакторы. Шестнадцатеричный редактор (hex-редактор) — это программа, используемая для проверки и изменения содержимого двоичных файлов. Данные обычно отображаются в виде целых чисел в шестнадцатеричном формате, отсюда и название. Большинство хороших шестнадцатеричных редакторов могут выводить данные в виде целых чисел от 1 до 16 байтов каждый, в 32- и 64-битном формате с плавающей запятой и в виде текста ASCII. Hex-редакторы особенно полезны при отслеживании проблем с бинарными файловыми форматами или обратном инжиниринге неизвестного бинарного формата.

Всё-таки ещё раз переделал оглавление канала, потому что то мне показалось не очень хорошим. А с этим оглавлением вы сразу найдёте тему, которая вам интересна

Статьи: Основы: Общие параметры сборки Самые распространённые системы контроля версий. Исходные файлы, заголовки и единицы компиляции Алгоритмика: Big "O" и сложность алгоритмов Сети: Заголовки безопасности HTTP(Заголовок Content Security Policy (CSP)) ЭТАЛОННЫЕ МОДЕЛИ СЕТИ(Модель OSI) Пакеты и маршрутизаторы Python: Полезные библиотеки C++: ПРОСТРАНСТВО ИМЁН Шпаргалки: Алгоритмика: Big "O" Сети: ЭТАЛОННЫЕ МОДЕЛИ СЕТИ(Модель OSI) Полезно: Пример возможной архитектуры информационной системы Простая реляционная схема реализации домашней страницы X(в прошлом: Twitter)

Общие параметры сборки Сегодня мы разберём некоторые из наиболее распространенных параметров, которыми вы можете управлять с помощью конфигураций сборки. Это я буду объяснять на примере языка программирования C++ Настройки препроцессора При подготовке программного кода к компиляции препроцессор C++ добавляет содержимое произвольных файлов (#include), а также определяет и заменяет макросы (#define). Чрезвычайно мощная особенность всех современных препроцессоров C++ — возможность определять макросы препроцессора с помощью параметров командной строки. Макросы, определенные таким образом, действуют так, как если бы они были записаны в исходный код с применением инструкции #define. В большинстве компиляторов для этого используется параметр командной строки -D или /D, причем может быть использовано любое количество этих директив. Эта особенность позволяет передавать различные параметры сборки для вашего кода, не изменяя сам исходный код. В качестве распространенного примера: символ _DEBUG всегда определяет отладочную сборку, в то время как сборки без отладочной информации характеризуются символом NDEBUG. Исходный код проверяет эти флаги и так узнает, собирается он в режиме отладки или без нее. Настройки компилятора Один из наиболее распространенных параметров компилятора определяет, должен ли компилятор включать отладочную информацию в создаваемые им объектные файлы. Эта информация используется отладчиками для просмотра вашего кода, отображения значений переменных и т. д. Отладочная информация увеличивает размер исполняемых файлов на диске и позволяет хакерам выполнить обратный инжиниринг вашего кода, поэтому ее всегда удаляют из окончательной версии исполняемого файла. Однако во время разработки отладочная информация неоценима и всегда должна включаться в сборки. Так же у компилятора есть множество других полезных функции, которые вы можете задействовать при своём желании. Настройки компоновщика Компоновщик также предоставляет ряд опций. Вы можете контролировать тип выходного файла — исполняемый файл или DLL. А еще указать внешние библиотеки, которые должны быть связаны с исполняемым файлом, и путь до папок, в которых стоит их искать. Обычная практика — связь с отладочными библиотеками при сборке исполняемого файла отладки и с оптимизированными библиотеками при сборке в режиме без отладки. Параметры компоновщика также управляют такими вещами, как размер стека, предпочтительный базовый адрес вашей программы в памяти, тип компьютера, на котором будет выполняться код (для оптимизации под конкретное устройство), включена ли глобальная (во время компоновки) оптимизация, и некоторыми другими мелочами, которыми мы здесь не будем заниматься. Спасибо за внимание, ставьте реакции, если понравился пост🔥 @programistica // #Статья #Основы #Общие_параметры_сборки

Добрый день! Помогите бустануть канал, чтобы мы могли создавать для наших статей более привлекательный внешний вид: https://t.me/boost/programistica Спасибо за внимание! 🔥

Исходные файлы, заголовки и единицы компиляции Сегодня я вам расскажу, что такое Исходные файлы, заголовки и единицы компиляции и как их представляет компьютер на примере языка программирования C++, но это и не сильно отличается в других ЯП. Программа, написанная на C++(но и на других ЯП), состоит из исходных файлов (source). Обычно они имеют расширение .c, .cc, .cxx или .cpp(это от языка к языку может отличаться) и содержат основную часть исходного кода вашей программы. Исходные файлы известны также как единицы компиляции, потому что компилятор переводит один исходный файл за раз из C++ в машинный код. Специальный вид исходного файла, известный как заголовочный файл (header),часто используется для того, чтобы единицы компиляции обменивались между собой информацией, такой как объявление типов и прототипов функций. Файлы заголовков не видны компилятору. Вместо этого препроцессор C++ заменяет каждое утверждение #include содержимым соответствующего заголовочного файла перед отправкой единицы компиляции в компилятор. Это тонкое, но очень важное различие. Заголовочные файлы существуют как отдельные файлы с точки зрения программиста, но благодаря расширению для обработки заголовочных файлов препроцессора все, что видит компилятор, — это единицы компиляции. Спасибо за внимание, ставьте реакции, если понравился пост🔥 @programistica // #Статья #Основы #Исходные_файлы_заголовки_и_единицы_компиляции

Простая реляционная схема реализации домашней страницы X(в прошлом: Twitter)

Самые распрасраненные системы контроля версий. Сегодня я вам расскажу о самых известных системах контроля версий и их особенностях 1.SCCS и RCS. Source Code Control System (SCCS) и Revision Control System (RCS) — две самые старые системы контроля версий. Обе используют интерфейс командной строки. Они распространены в основном на платформах UNIX. 2.Concurrent Version System (CVS) — это высокопроизводительная система управления исходным кодом профессионального уровня на основе командной строки, изначально построенная на основе RCS (теперь реализована как само- стоятельный инструмент). CVS распространена в системах UNIX, доступна и на других платформах разработки, таких как Microsoft Windows. Имеет открытый исходный код. 3.CVSNT — это реализация для Windows, которая основана на CVS и совместима с ней. Subversion. Система контроля версий с открытым исходным кодом, призванная заменить и улучшить CVS. 4.Git. Система контроля версий с открытым исходным кодом, которая исполь- зовалась во многих легендарных проектах, включая ядро Linux. В модели разработки Git программист вносит изменения в файлы и фиксирует перемены в ветке. Затем он может быстро и легко объединить свои изменения в любую другую ветку кода, потому что Git знает, как перемотать последовательность изменений и повторно применить их к новой базовой ревизии. 5.Perforce. Система контроля версий профессионального уровня с текстовыми и графическими интерфейсами. Она известна прежде всего своей концепцией списка изменений (changelist). Любое исправление в репозитории однозначно определяется пронумерованным значением changelist, включающим в себя изменения файлов (одного или нескольких тысяч). Поэтому вносимые изменения применяются или для всех файлов из списка, или ни для одного. Perforce используется многими игровыми компаниями, включая Naughty Dog и Electronic Arts. Спасибо за внимание, ставьте реакции, если понравился пост🔥

Пакеты и маршрутизаторы Сегодня я вам расскажу об очень важном нововведении, позволившим сообщениям быстрее перемещаться по сети с несколькими переходами А именно стало разбиение каждого сообщения на небольшие фрагменты, которые впоследствии отправлялись по отдельности. В области сетевых коммуникаций эти сообщения называются пакетами. Сперва использовался такой принцип: при разбиении сообщения на отдельные пакеты, если короткое сообщение было отправлено после длинного сообщения, первому не приходилось ждать завершения отправки второго. Вместо этого первому пакету короткого сообщения требовалось дождаться лишь завершения отправки текущего пакета длинного сообщения. До тех пор, пока короткое сообщение не было отправлено полностью, а передача длинного сообщения не возобновилась по полному сетевому соединению, система чередовала отправку пакетов этих сообщений. Разбиение сообщения на пакеты значительно сократило объем памяти, требующейся от промежуточных устройств. Теперь вместо того, чтобы хранить сообщения в течение нескольких часов, им достаточно было хранить некоторое количество пакетов лишь несколько секунд, а остальные пакеты ожидали своей очереди на исходящем канале. По мере отказа от сетей с промежуточным хранением начали появляться особые устройства, специализирующиеся на транспортировке пакетов. Первоначально они назывались интерфейсными процессорами обработки сообщений (Interface Message Processors – IMPs) и представляли собой интерфейсы между обычными устройствами и остальной частью сети. Позже эти устройства получили название маршрутизаторов, поскольку их цель заключалась в маршрутизации получаемых пакетов к конечному месту назначения. С появлением маршрутизаторов, специализирующихся на транспортировке пакетов по сетям с несколькими переходами, подключать устройства разных производителей к одной сети стало намного проще. Все, что для этого требовалось, – подключить обычное устройство к маршрутизатору. Остальную же работу по организации связи выполняли другие маршрутизаторы. Если несколько устройств, находящихся рядом, были объединены в локальную сеть (Local Area Network – LAN) с помощью физического провода, следовало подключить маршрутизатор к локальной сети. Затем, после отправки данных через маршрутизатор все устройства в этой сети могли отправлять данные дальше через глобальную сеть (Wide Area Network – WAN). Всем большое спасибо за внимание, вот такой у нас получился экскурс в историю появления сетей и передачи информации по сети, ставтьте реакции, если вам понравился такого рода материал!🔥

ПРОСТРАНСТВО ИМЁН В C++ Сегодня я вам расскажу, что такое пространство имён и для чего оно нужно, в одном из моих любимых языков программирования, C++ Пространство имен — это область, в рамках которой определяются различные идентификаторы (имена типов, функций, переменных, и т. д.). Пространства имен используются для организации кода в виде логических групп и с целью избежания конфликтов имен, которые могут возникнуть, особенно в таких случаях, когда база кода включает несколько библиотек. Проще говоря, пространство имён предопределяет те, символы и имена, которые можно использовать в вашем коде. Все, кто работал с языком C++, знают, что в языке есть стандартное пространство имён: std. Именно в нём хранятся название основных типов данных, методов языка. И именно из-за пространства имён, когда вы пытаетесь назвать переменную или функцию именем, которое уже зарезервировано в пространстве, то компилятор выдаёт ошибку. Так же если в коде не указывать пространства, то компилятор, просто, будет не понимать, что это за имя такое, вот например:

#include <iostream>
int main()
{
    cout<<"Hello World";

    return 0;
}

Данный код разумеется выведет ошибку, вот как она будет выглядеть: error: ‘cout’ was not declared in this scope; Это означает, что компилятор не понимает, что такое функция cout, ведь это имя содержится в пространств имён std. Вот примеры, где ошибок уже не будет:

#include <iostream>
using namespace std;
int main()
{
    cout<<"Hello World";

    return 0;
}

ИЛИ можно использовать оператор разрешения области (::)

#include <iostream>
int main()
{
    std::cout<<"Hello World";

    return 0;
}

Так что все стандартные типы и функции библиотек C++ объявляются в std пространстве имен или пространствах имен, вложенных внутри std. Давайте так же уделим немного времени вложенным пространствам имён. Вложенные пространства имен Пространства имен могут быть вложенными. Обычное вложенное пространство имен имеет неквалифицированный доступ к членам родительского элемента, но родительские члены не имеют неквалифицированного доступа к вложенному пространству имен (если он не объявлен как встроенный), как показано в следующем примере:

namespace std{
    void zeb()
    {
        //Ваш код
        namespace Details{
            void foo{
                //Ваш код
            }
        }
        //Ваш код
    }
}

Вот так это примерно выглядит. Думаю можно на этом завершить. Спасибо за внимание! Ставьте реакции, чтобы я знал, что вам интересно, оставляйте комментарии с вопросами, будем и на них отвечать🔥 @programistica // #cpp #Пространство_имён

Пример возможной архитектуры информационной системы @programistica // #Шпаргалка #Информационные_системы

Спасибо за полезную инфу. Было бы не плохо если добавляли бы тэги. Типо #заголовкибезопасности, тыкнул, и на тебе все посты по заголовкам)

Один из подписчиков предложил поменять систему тегов на канале. И нам показалась эта идея очень хорошей, ведь она поможет смотреть вам те посты, тематика которых вам больше всего нравится. Мы уже изменили систему тегов, пост со всеми тегами находится в закреплённом сообщении(Теги будут ещё дополнятся по мере выхода постов) Но есть небольшой недочёт, новые теги подходят только для постов, выпущенных после 28 января. Надеюсь новая система тегов вам понравилась!❤️ Так же пишите в комментарии, на какие темы вы хотели бы видеть ещё посты🔥

Модель OSI

ЭТАЛОННЫЕ МОДЕЛИ СЕТИ В этой статье я вам расскажу об одной из основных эталонных моделей, как OSI. В основе OSI лежит проект, разработанный Международной организацией по стандартизации (lnternational Standards Organization, ISO). Это был первый шаг к международной стандартизации протоколов, используемых на различных уровнях. Модель была пересмотрена в 1995 году и получила название эталонной модели взаимодействия открьтых систем ISO (ISO OSI (Open Systems Interconnection) Reference Model). Она описывает вопросы соединения открытых систем, то есть таких, которые открыты для обмена информацией с другими системами. Эта модель включает 7 уровней, выделенных согласно следующим принципам: 1. Каждый уровень соответствуют отдельной абстракции. 2. Все уровни выполняют четко определенные функции. 3. Функция каждого уровня выбирается с учетом создания в дальнейшем международных стандартизированных протоколов. 4. Границы уровней должны выбираться так, чтобы минимизировать поток информации через интерфейсы. 5. Количество уровней не должно быть слишком низким, чтобы не приходи- лось собирать разные функции в одном уровне; но нельзя, чтобы их было чересчур много, иначе архитектура будет громоздкой. Центральными для модели OSI являются три понятия: 1. Службы. 2. Интерфейсы. 3. Протоколы. (Ниже я выложу фотографию, которая иллюстрирует строение OSI) Вероятно, главная ценность модели OSI - четкое разграничение этих поня- тий. Каждый уровень предоставляет вышележащему уровню какие-либо службы. Определение службы говорит лишь о том, что делает данный уровень, но не о том, как вышележащие уровни взаимодействуют с ним или как он работает. Надеюсь вам понравилась статья по этой теме, ставьте реакции, если хотите узнать больше по этой теме!!!

Модель OSI

Я честно удивлён, что в голосовании победил python. Но я решил сперва посоветовать вам несколько крутых библиотек, которые используются в Веб-разработке. Scrapy Scrapy – это библиотека, с которой удобно собирать данные для вашего приложения. Ее используют для написания поисковых роботов (веб-краулеров) и других алгоритмов для сбора данных. Она поддерживает асинхронность и поэтому позволяет быстро и эффективно решать самые разные задачи: от загрузки веб-страниц до их обработки и сохранения в различных форматах. Dash Dash — это библиотека Python для работы над веб-приложениями. Ее отличает доступный инструментарий для создания графических интерфейсов (GUI), через которые пользователь может работать с данными. А еще в ней удобно делать приложения с интерактивными диаграммами, графиками, дашбордами. HTTPX HTTPX — одна из главных библиотек для бэкенд-разработчиков. В отличие от другой популярной библиотеки — Requests, HTTPX позволяет работать не только с синхронными, но и с асинхронными HTTP-запросами. Эта библиотека также поддерживает современную версию протокола — HTTP2 и довольно проста в использовании. 🔥Надеюсь, они вам пригодятся!

Заголовки безопасности HTTP В этой статье мы поговорим о таком заголовке безопасности, как Content Security Policy (CSP) Content Security Policy (CSP) - это дополнительный уровень безопасности, который помогает обнаруживать и смягчать определенные типы атак. включая Cross-Site Scripting и атаки с внедрением данных. Чтобы включить CSP, необходимо настроить веб-сервер так, чтобы он возвращал HTTP-заголовок Content-Security-Policy. Использование CSP Настройка политики безопасности содержимого включает в себя добавление HTTP-заголовка Content-Security-Policy на веб-страницу и присвоение ему значений, определяющих, какие ресурсы агенту пользователя разрешено загружать для этой страницы. Например, страница, которая загружает и отображает изображения, может разрешать изображения из любого места, но ограничивать действие формы определенной конечной точкой. Правильно разработанная политика безопасности содержимого помогает защитить страницу от атаки межсайтовых сценариев. Вот пример указания политики:

Content-Security-Policy: policy

Теперь давайте разберём пару практических примеров: Пример 1: Администратор веб-сайта хочет, чтобы все содержимое поступали из собственного источника сайта (за исключением поддоменов)

Content-Security-Policy: default-src 'self'

Пример 2: Администратор веб-сайта хочет разрешить доступ к содержимому из доверенного домена и всех его поддоменов (это не обязательно должен быть тот же домен, на котором настроен CSP)

Content-Security-Policy: default-src 'self' example.com *.example.com

Тестирование политики Чтобы упростить развертывание, CSP можно развернуть в режиме только отчета. Политика не применяется, но обо всех нарушениях сообщается по указанному универсальному коду ресурса (URI). Для указания политики можно использовать HTTP-заголовок Content-Security-Policy-Report-Only, например:

Content-Security-Policy-Report-Only: policy

Включение отчетности По умолчанию отчеты о нарушениях не отправляются. Чтобы включить отчеты о нарушениях, необходимо указать директиву политики report-to, указав по крайней мере один универсальный код ресурса (URI), по которому будут доставляться отчеты:

Content-Security-Policy: default-src 'self'; report-to URI

Синтаксис отчета о нарушениях blocked-uri Универсальный код ресурса (URI) ресурса, загрузка которого была заблокирована политикой безопасности содержимого. Если заблокированный URI получен из другого источника, чем , то заблокированный URI усекается, чтобы содержать только схему, хост и порт document-uri Универсальный код ресурса (URI) документа, в котором произошло нарушение. original-policy Исходная политика, указанная в HTTP-заголовке. referrer Реферер документа, в котором произошло нарушение. А чтобы больше про это узнать, советую прочесть следующие книги: Компьютерные сети. 6-е изд. | Уэзеролл Дэвид, Таненбаум Эндрю Компьютерные сети. Принципы, технологии, протоколы: Юбилейное издание | Олифер Виктор Григорьевич, Олифер Наталья Викторовна