Александр

Добрый вечер! Столкнулся с такой проблемой: Мне очень нравятся семейство языков Си, у меня есть выбор учить C++ либо C#, хочу разрабатывать ПО для ПК. Подумал начать с C++ и говорят что сначала поучить чистый СИ, а после переходить на C++, так что же из этого правильно? Надо ли учить Си? Или может лучше начать с C#, а дальше уже выучу C++?

Тема сравнения С/C++/C# в публичном пространстве - опасная тема. Она обычно заканчивается
топиком в 1000 страниц и великой войной всех против всех. Я видел много таких войн.
Они ничем не заканчиваются. Специалисты остаются при своих мнениях. А зритель просто развлекается.

Сам по себе выбор языка ставят только новички. Професиионалу безразличен язык (почти). Его может больше интересует отрасль, стек технологий, стандарты и протоколы. С моей точки зрения сегодня
таким стандартом может быть выбор облака (AWS, Azure, GCP).

Чистый СИ учить смысла нет. Учи сразу С++. Но даже его создатель Бьорн Страуструп считает что С++ это
сложный язык и он настаивает чтобы новички не брались учить все фичи сразу. Исключение по языку
СИ может быть в том случае, если ты собрался быть инженером по разработке микро-контроллеров
и у тебя скорее всего будет только СИ как основной (на 80-90%) инструмент взаимодействия с таким железом. Выйти на мидловый или синьорный уровень в С++ очень тяжело. Тяжелее чем в других языках.
Поэтому будь готов терпеть. Вот когда виски станут седые - тогда и будешь господин-синьор.

C# - это очень сильно корпоративный стандарт от Microsoft. Никакой связи с С++ он не имеет. Он конечно
внешне похож но это сходство обманчиво. Да изучать его тоже можно. Он учится легко. Существуют книги
вроде ".... C# за 14 дней". Разработка бизнес-приложений на шарпах идет гораздо быстрее чем на С++
например. И завалить систему в синий экран в этом языке гораздо труднее. В нем реализованы методы
защиты памяти и нельзя грязно трюкачить с указателями как это любят в С или С++. Производительность
шарпов в численных методах будет слабее чем в С++ но обычно бизнес не ставит таких задач и чаще
надо будет писать веб-хендлеры или хендлеры MQ-систем. Кач уровней синьорити идет быстрее в шарпах.

Ассемблер полезен при анализе прошивок на безопасность.
При изучении того как работает софт без исходного кода (обратный инжинеринг)
и при решении задач интеграции разных слоёв софта.

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

Ассемблер помогает при анализе узких мест в коде. В частности например
векторизация вычислений ставит в первую очередь вопросы на которые ассемблер
отвечает а ЯВУ - нет.

Знания ассемблера помогают сделать бинарник компактнее. Это важно при разработке
встраиваемых систем.

1) Можно создать 7 фолдеров типа /disk1, /disk2 .... и примонтировать диски через mount.
2) Можно собрать ZFS pool из 7 дисков и подключить их все как один большой диск (zpool create).
3) Программный JBOD на базе Btrfs (mkfs.btrfs ... )
4) LVM как уже писали выше

1. Java (JDK/JRE) не содержит в себе драйверов доступа к БД вообще. В ней определен только базовый
интерфейс java.sql.* и существует некий стандарт на то как драйверы должны работать. Например когда мы делаем ResultSet::close, или Statement::close, драйвер может ничего и не делать в этот момент. Все зависит от того
как производитель (Oracle, MSSQL) реализовал под капотом работу драйвера. Поэтому как работает внутри драйвер это - тайна.

2. Обычно если в приложении тебе часто и много нужно создавать объектов Connection, то используют пулы коннектов (Hikari Connection pool, DBCP, C3PO). Почитай в этом направлении. Пулы экономят сессионные
объекты на стороне БД и создают новые коннекты быстрее за счет переиспользования сущесвтующих коннектов.
В обычном (прямом режиме) работы с БД процесс установки соединения может занимать несколько секунд.
Это может быть запредельно медленно для некоторых алгоритмов.

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

Бизнес успех таких сетей как VK, Facebook слабо связан со стеком. Они все стартовали с PHP но просто
очень умно кешировали контент и децентрализовывали. Поэтому в первую очередь важен скилл
специалистов которые будут видеть узкие места в системе и сумеют быстро их пофиксить.

Популярность.

Я-бы не брал в расчет вообще. Сервисы yahoo в свое время создавались на Lisp, а это был вообще
нигде не популярный язык.

Скорее всего коды SQL ошибок зависят от DBMS. Например я по старой памяти помню что если
в коде вы видите ORA-00001 то вы скорее всего используете Oracle и ваша ошибка
связана с нарушением Primary KEY во время INSERT/UPDATE.

Другие DBMS (Postgres/MySQL) будут иметь другие коды ошибок.

В конце 20-го века, когда Эдгар Кодд развивал свою реляционную теорию было очень
модно все данные нормализовывать для хранения их в БД. Это соотвествовало экономии
ресурсов (диски мерялись килобайтами и мегабайтами) и нормализация хорошо ложилась на
техно-стек. Все данные должны быть атомарны. И ты - плохой DBA и программист если
кладешь в ячейку что-то более комплексное чем просто атом.

В 2000х развитие веб и XML(XHTML/SGML, XSLT, XPath) дало толчок новым видам
хранения информации в виде markup languages. Появляются технологии семанического веба.
Мечтатели-теоретики создают RDF, OWL. Базы данных пытаются успеть втянуть в себя новые типы.
Oracle начинает поддерживать XML+Schema как тип данных в таблице. Браузер начинает
поддерживаеть трансформацию XML и обогащение его стилями. XML - моден. Его внедряют
везде где можно и где не нужно. Даже в конфигах Apache Http и в сборщике Maven.

Параллельно Дуглас Крокфорд работает над Java Scrip Obj Notation и создает лайтовый язык
для описания объектов и документов. Они - конкурируют с XML но JSON практически побеждает
в вебе, полностью захватывая веб протоколы (Ajax, WebSockets, e.t.c). И интеракцию с сервером.
JSON становится более популярный для REST. Многие БД тоже начинают поддерживать JSON.
Postgres даже делает бинарный JSON и добавляет спец-индексы для быстрого поиска атрибутов.
Узко-специализированные системы такие как Mongo изначально заточены на храннение JSON
информации.

BigData плавно проростает в 2007 (кажется) и где-то в 2014 (или позже) году фреймворк Spark начинает поддерживать DataFrames + Structured Types которые по сути являются зеркалом JSON. Фреймворк
позволяет грузить в бигдату JSON-lines датасеты, автоматически выводя схему.

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

Если поискать анти-паттерны применения JSON в базах данных - то я-бы предложил такую метрику.
Если вы очень часто обновляете маленькое поле внутри большого JSON документа и это создает
сильные I/O нагрузки то скорее всего вам надо перепроектировать вашу БД как-то по другому
и вынести это поле во вне по отношению к документу

Почему все методы StringBuilderнельзя было поместить в класс String, чтобы не плодить классы строк?

Главный поинт при создании immutable String - безопасность кода. Когда компиллятор точно
знает что value строки не изменится - то он может доказать много кейсов и гарантировать что
разделяемая память не будет сломана. Особенно это важно для мультипоточки. Когда
разные потоки владеют строкой и здесь сам вопрос доказательства вдруг становится очень важным.

Язык С++ например такой защитой не обладает и для него строка как фундаментальный тип
может иногда мутировать. Тоесть если вы старались писать правильно то она конечно не мутирует.
Но в этом есть большая разница между C++ и Java. На уровне платформы гарантировано отсуствие
какого-то класса ошибок.

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

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

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

Обычно если хост отдается под сервер баз данных - то он отдается целиком и полностью.
Как - женщина в браке. Не может быть варианта использования наполовину. Типа
веб-сервер + еще БД.

Оно понятно что Express - это такой пробник. Но этот пробник все равно в перспективе перерастет
в БД. И зачем тебе размениваться на мелочах?

База всегда брала столько памяти сколько есть. Потому вто буферный кеш БД или кеш блоков
(его по разному называют) играет роль ускорителя для таблиц и индексов. Грубо говоря
чем больше блоков в кеше - тем быстрее идет интеракция с data-files.

Уберите из docker-compose
"ports:
- "5400:5432"
и порт не будет публиковаться наружу, будет доступен только на внутреннем ip адресе вашего контейнера docker.
Для подключения или используйте внутренние имена контейнеров, или создайте отдельную подсеть docker (подсеть по умолчанию не дает выдавать контейнерам статические ip адреса) и переведите оба контейнера на ее использование с выдачей статических ip адресов.

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

))) Все решил)) В компиляторе тоже надо поставит 13 версию.