mayton2019

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

Свой личный код - можно но я тебе очень сильно не советую это делать с рабочей машины.
Миллион раз были случаи когда параметры user.name/user.email из конфигураций github
утекали в commit и по этим признакам очень легко было найти утечки. Причем я подозреваю
что у самого гитахба есть бигдата джобы которые сканят код на предмет бизнесовых торговых
марок и лейблов. Эти параметры можно менять и конфигурить для каждого проекта
но я все равно не советую. Имя пользователя ПК у меня некоднократно утекало почемуто
в MANIFEST.mf (так работал maven в дефолтной комплектации) и бог его знает сколько сюрпризов
вообще таят в себе современные компилляторы. Короче набей себе татуху на левой руке
"Never commit from Corporate Desktop! Never! You!"

Подобоный bash мониторинг может создавать ненужную нагрузку (например если ты ишешь через find)
а файлов очень много. Они мелкие и т.п. Вобщем если искать часто (каждые 5 минут - то это будет ненужная
нагрузка). А если искать редко - то какая польза в таком мониторинге?

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

Есть у меня мысль - поднять информацию не из файлового API (find/du/ncdu) а из таблиц inode.
Там как раз есть информация о размере. Оптимистично - это более быстрый метод. По крайней
мере факт превышения квоты будет виден. А вот кем - надо искать.

Еще есть мысль что контроль квот - это технология уходящего века. В мире современных файловых
систем никто давно уже не учитывает файлы. Создается толстое хранилище на базе zfs например.
Оно нарезается пользователям на кусочки по 16/32/64 Gb и отдаются в пользование. По ним-же
идет тарификация. Если пользователь захочет больше - на ходу ему растягивается кусочек до нужного
ему размера. Тариф соотв другой.

Диагностику протокола SSL/TLS можно сделать с помощью утилиты OpenSSL например
вот как тут пишут https://stackoverflow.com/questions/17742003/how-t...

Чтобы браузер полноценно работал с секретным протколом - ему нужен сертификат домена.
Я тут не уверен можно ли создать само-подписный сертификат для localhost но мои знакомые
девопсы хвастались что делали такое.

Для создания сертификатов полно инструкций.

JSON хорошо подходит для хранения неспецифицированных данных. Например у вас есть таблица товаров.
У товара есть базовые свойства такие как цена, категория, название и производитель.
А есть описалово товара где например для ТВ-панели будет около 50 параметров таких как диагональ,
яркость матрицы, и прочая техническая чепуха. Вот эти 50 параметров можно положить в JSON (или JSONB)
для Postgres. Потому что в магазине всегда есть прецензиозные клиенты которым нужна посудомойка розового цвета и встраиваемая и еще ценой такой-то и такой-то. Вот спецом для них такая структура может быть создана.

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

Мне кажется что флеш был уникален тем что сочетал в себе сразу 3 вещи. И среду разработки. И язык разработки. И плагин рендеринга векторной графики в браузере.

Дизайнер который решил заниматься флешем просто его устанавливал и получал себе возможность создавать свой креатив сразу. Если брать JS то надо искать среду в которой можно рисовать векторную графику и анимировать ее. Есть ли такая среда - я не знаю.

В прошлом были истинно программистиские решения такие как Java Applets но они не взлетели как раз
именно по причине того что были ориентированы на программиста а не на дизайнера. Дизайнеру
и в страшном сне не присниться писать java-код.

Если смотреть в сторону Unity то там вроде-бы можно сделать многое. Но там чорт-пойми какая лицензия
и создатели Unity закручивают гайки постоянно. А если ты - "вкатыш" в эту технологию то ты как-бы
интуитивно ищешь нечто свободное и либеральное к использованию. Желательно - opensource.

Да. Но Ethernet это очень общий термин. А ты скорее всего имел в виду какой-то конкретный разъем. RJ-45 наверное
и с какой-то скоростью (10/100mbit или гигабит).

Конвейер компилляции С++ точно не прост. На хай-левеле это 3 шага. Препроцессор, компилляция и линкер.
А сама компилляция в свою очередь тоже сложна. Там полюбому будет работа с шаблонным процессором
и еще будет обязательно проход оптимизации. Это когда из кода можно выкинуть недостижимые ветки или
размотать циклы. И это тоже шаг.

Задача состоит из двух частей. Первое это чтение документа по словам. Вот как тут пишут
https://www.geeksforgeeks.org/python-program-to-re...

И второе, когда поток слов уже есть - добавить их в словарь с генерацией порядкового номера.

num = 0
word_dict = {}

// в теле цикла
if not (word in word_dict):
  word_dict[num] = word
  num = num + 1

Можно. Весь 20-й век почти так делали. База была главной. Эдакая себе царица. Ее любили. Холили.
Приложения были двухзвенки. Оконная апликуха коннектилась к базе и все расчеты
проводились в базе. Апликуха только показывала результаты в гридах и вводила формочки.
Джобы тоже запускались в базе как процедуры на PL/SQL по скедулеру. Для пуска их клиент
был тоже не нужен. Плановые задачи БД запускала самостоятельно. Это и было видение
бизнес логики из 20-го века.

В 21-м веке с развитием веба появился слой middle. И разработчики вынесли в него максимальную
часть логики. Это произошло естественным путем. А базе досталась участь быть просто хранилищем
таблиц. Потому что держать 2 копии логики или поддерживать было уже неудобно. В команде
должен быть тогда разработчик и Java и PL/SQL одновременно. В современной парадигме
разработки с ORM база стала просто чем-то вторичным. И на уровне ORM абстракций
даже заменяемым на другие типы баз.

Но не все так плохо.

Фактически, логика современного приложения размазана по 3м слоям. Даже в браузере
есть какая-то минимальная логика, например при аутентификации или при проверке
валидности емейла. И какая-то логика агрегации (sum/group by) полюбому есть в базе.
Потому что агрегировать в приложении все - глупо. Это лишний трафик.

И нет такого архитектора который говорит "нельзя". Просто есть best-practices современной разработки,
исходя из развитя железа, сетей и вообще рынка всего остального. Кто знает может в мобилах вернуться
к двузвенкам. Смотря под каким углом смотреть на современные мобильные приложения? Who knows.

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

Вот это все

neuron
layer
network

я-бы на твоем месте не делал. Это уже архитектура и интеграция. Если развивать проект дальше.

И ты должен сам себе ответить на вопрос - что ты хочешь изучать. ООП или нейросети.
Нейросети это тяжелая тема. Там много экспериметов. Много разочарований. Много работ
дата-инжениринга по сбору и фильтрации входных данных. И этого всего настолько много
что для ООП там уже сил не остается. Тоесть твоя декомпозиция задачи на 3 класса на старте
тебе ничего пока не дает. Но обязывает тебя очень многому.

Я-бы предложил делать прототип в олипиадном стиле.

По поводу примерв. На гитхабе я находил много туториалов и пробных нейросетей на сях
созданных в рамках обучения. Я искать их не будут. Я думаю ты сам найдешь.

Я могу ошибаться но ток зарядки определяется по протоколу Power Delivery. Это должен быть диалог
двух умных устройств. Телефон и зарядник который это поддерживает.

UPD: Я думаю что провод здесь непричем. Я думаю что он может нагреться и из него дым пойдет
но зарядник и телефон будут считать что все в порядке.

Пули вышли из ствола.

Ну в твоем уравнении x = π .

Чисто π является трансцедентным числом. Также как и число e. Их алгоритм расчета - бесконечные ряды
поэтому под определение это вполне себе подходит.

Ну есть лучше подход. Допустим у тебя 54 тыщи строк и ты хочешь получить 5.4 тыщ. Тоесть тебе
надо грубо говоря удалить 9 строк и десятую оставить.

Для меня это задача - на программирование. И я честно говоря не знаю как ее решать в текстовом
редакторе. Не если ты будешь брать хеш-функцию от каждой строки и брать от нее по модулю 10
то как раз на выходе выйдет что всте остатки от 0 до 8 можно вышвырнуть а остаток 9 - взять.
И таким образом будет фильтрация с понятным коэффициентом.

Если ты будешь делить пополам то ты получишь тестовые данные не точного размера. Промахнешся.
И получишь сильно коррелированные данные. Тоесть они будут как-бы отфильтрованы через высокочастотный
Фурье.

Не отрезолвился потому что ближайший DNS выдал чепуху.
Попробуй вручную понаблюдать что отдает DNS по данному хосту
через утилиты nslookup, dig e.t.c.