m1t9.(；

Нужен огромный и продолжительный труд, чтобы написать приличную книжку.
Чтобы в ней было не 10 страниц, а много хорошего материала, с примерами, с задачами, с изложением. Оформить, вычитать, отредактировать, договориться с издателем, выпустить, получить какую-то отдачу.
Хорошую книгу ты читаешь долго. Месяц, два, год. Перечитываешь.

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

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

Также видео делать сложнее, чем писать текст. Гораздо дольше. Гораздо дороже.
Редактирование видео вещь в разы более муторная, поэтому чаще просто переснимают короткие блоки, а это опять таки непросто.
То есть сделать видео с таким же качеством материала и с такой же плотностью материала - в десятки раз дороже по всем ресурсам - деньги, время, оборудование.
И при этом никто не будет смотреть месяц видео (160 часов, например). Никто не будет делать поиск внутри видео, закладки на нужные отрывки и использовать видео как справочник.

Перенести материал из книги перенести в видео - это непомерный труд с одной стороны и совершенно невостребованный с другой стороны.
А поэтому никто не делал, не делает и не будет делать видео с таким же наполнением материалом, как это можно сделать в тексте.

Видео - это разок посмотреть на чей-то практический материал, разок посмотреть как это делает кто-то другой.

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

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

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

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

P.S. Одним из самых важных минусов видео я считаю то, что ты не можешь получать информацию в комфортном для себя темпе, с возможностью быстро перечитать слово/фразу и обдумать ее. Сам читаю множество лекций, и эта проблема, когда скажешь 2-3 предложения быстрее, чем обычно и половина учеников отваливается с бессмысленным взгядом. Так на живом курсе ты можешь обратить на это внимание и перефразировать, а записанное видео уже не изменишь.

Если честно, то на рынке ИТ все сейчас очень сложно. Причин несколько, а анализ легко растянется на полноценную статью, даже была мысль написать наХабр и Линкедин по этой теме. Постараюсь коротко пройтись по основным трендам.
1. Доступность удаленной работы, соответственно регионы и Индия с низкими зарплатами ворвались на рынок.
2. Миф о высокой зарплате. Когда то так было, сейчас курьер Яндекс-еды зарабатывает больше, чем средний программист. Про продажников даже не хочу говорить, знаю людей, легко имеющих и по миллиону в месяц.
3. Мифы о легком старте. На самом деле точка входа в профессию достаточно высока, так как мало освоить навыки кодера, нужно еще иметь логическое мышление, знать математику, анализ, разбираться в предмете (физика для игр, экономика для 1С, производство для автоматизации и многое другое). И, возвращаясь к пунктам 1 и 2, за хорошую зарплату придется после пары месяцев курсов конкурировать с индусами, которые имеют по 10 лет опыта, с регионами, где есть специалисты с 20-летним опытом, готовые работать за зарплату джуна в Москве.
4. Отдельно выделю сильно усложнившиеся программы, сложность разработки, несмотря на множество облегчающих жизнь инструментов, за последние годы выросла достаточно сильно.

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

Надеюсь, ответил достаточно понятно)

Простой в реализации метод: держите отрезки в каждом элементе отсортированными и непересекающимеся (если два отрезка пересекаются - объедените их).

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

Если же список очень длинный, а ответ ожидается маленький, то есть более быстрый метод. Но он сложный в реализации. Нужно реализовать персистентное дерево поиска. Можно его реализовать на основе персистентного дерева отрезков. Это такая структура, в которую можно добавлять элементы, и удалять их за O(log n). Также можно обходить все элементы за O(log n + (их количество)). Кроме того, сохраняются все версии дерева после каждой операции и общее количество памяти будет O(к log n), где к - количество операций.

Эта структура будет использоватся для хранения предподсчитанных ответов. Если все ваши отрезки нарисовать на одной прямой, то она разобъется на O(n) отрезков, все точки которого будут давать один и тот же ответ при запросе. Мы эти все ответы компактно сохраним.

Используем метод сканирующей прямой. Нанесите все границы всех отрезков на одну прямую, пометив их как начало или конец (и какому элементу списка они соответствуют). Если пройтись по этой прямой слева на право, то будут происходить события - отрезки откроются (новый элемент добавляется в ответ) или отрезки закроются (элемент из ответа удалится). Поддерживая текущий ответ в персистентной структуре мы сильно экономим память. Удобно в качестве начал отрезка брать их координаты, а в качестве конца - координаты концов+1. В таком виде все границы отрезков будут точками, а не числами.

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

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

Это решение требует O(n log n) памяти (где n - количество всех отрезков) и O(n log n) времени на предподсчет и O( log n + (ответ)) времени на обработку ответа.

Более простое решение, где ответы считаются так же сканирующей прямой, но сохраняются просто в виде списков, а не версий персистентного дерева, может требовать O(n^2) памяти. Но будет работать быстрее, конечно.

Нет, не стоит.
Необходимо добавить памяти до 8Гб и поставить SSD

Господи, опять очередные страдания, "люди добрые памажите решить чем мне заниматься, мы сами не местные пять семей по вокзалам". У вас у всех прямо гамлетовские страдания, "быть или не быть". Вопрос века, ошибка смерти подобна - "в какой области я больше бабла получу???!!!111" Да ни в какой. Никому ты не нужен, такой беспомощный нытик. Ни в вебе, ни в энтерпрайзе.

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

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

НИ В КАКОЙ. В прошлом веке кончились те времена, когда ты выбирал себе профессию на всю жизнь. Сейчас мир меняется если не за 2 года, то за 10 лет неузнаваемо. Важны способности, а не навыки. Важно понимать общие принципы построения программных систем, а не конкретный синтаксис одного языка. Да, возможно через 5 лет разработчики БД будут совсем не нужны (на самом деле нет). Но я тебе точно говорю что и через 5, и через 50 лет будут нарасхват люди с мозгами и руками. И надо не затачивать свои руки под один конкретный инструмент, а разивать мозги, учить теорию, учиться самостоятельности, пытаться стать исследователем, а не мелким лавочником.

Как я сам переходил с постоянной работы на Upwork:
сначала брал небольшие заказы и делал их в свободное время. Заказов становилось всё больше. В какой-то момент подработка по вечерам стала приносить столько же денег, сколько основная работа full-time. В этот момент решил, что пора полностью уходить во фриланс.
Уволился. Стал фрилансить фулл-тайм. Поначалу было сложно забить всё свободное время, но даже при 50% занятости по деньгам выходило лучше, к тому же полная свобода, постоянно новые задачи.

Теперь по твоим вопросам.
1) Первое время необязательно заморачиваться за законность. Пока не выйдешь на стабильный доход хотя бы 100к/месяц, париться особо не за что. Можешь выводить деньги на PayPal или Payoneer или другими полулегальными способами. На первых порах лучше сосредоточиться на работе.
2) Когда появится стабильный ощутимый доход, то нужно регистрировать ИП, открывать расчётный счёт. В качестве налогообложения либо патент, либо упрощёнка 6%. Особо ничего сложного, инфы в инете в и на тостере куча.
3) Обычный расчётный счёт для ИП. На упрощёнке платишь 6% со всех доходов, которые поступают на счёт, платить нужно в определённые даты, чтобы налоги взаимовычлись с обязательными взносами ИП.
На патенте платишь годовую стоимость патента и обязательные годовые взносы и больше ничего. Далее только ведёшь КУДиР.
Нужно выбрать как вести бухгалтерию: электронные системы (Эльба, Моё Дело); услуга бухгалтера от банка или стороннего сервиса; наёмный бухгалтер; или тупо самому в экселе. Я пользуюсь первым способом.

4) В классическом фрилансе (когда делаешь заказ за заказом) действительно редко бывает энтерпрайз. Там обычно небольшие конечные проекты. Но когда долго работаешь на фрилансе, то начинает надоедать постоянный поиск клиентов и стремишься к одному большому проекту. По сути фриланс в какой-то момент перерастает в удалённую работу. И тут уже вполне может быть энтерпрайз. По технологиям это ты сам для себя решай. Нужно посмотреть, какие есть проекты, что востребовано. Возможно что-то подучить.

Здравствуйте!
Скажите пожалуйста, каким IDE вы собираете проект? Если Intellij IDEA, то мне эта проблема уже знакома...
Не раз натыкался на нее... В общем, когда вы собираете jar, то почему-то intellij idea если выбрать create jar from modules & dependencies создает jar некорректно. Эта проблема актуально до последней версии. И соответственно, в jar не попадает папка META-INF И файл MANIFEST.MF
Чтобы это исключить создайте jar - empty
Сама ошибка говорит о том, что в jar файле у вас нет вышеуказанного файла и папки. Тогда заработает корректно.
Также, если это maven || gradle, то положите папку meta-inf на уровень проекта, либо в папку resources. Не в java!
Вот, тут мой ответ по данному вопросу (со скриншотом) - https://stackoverflow.com/questions/1082580/how-to...

Shift + F6 or Top Menu -> Refactor -> Rename

Если вы загляните в публичные репозитории, типа mvnrepository.com, откуда gradle скачивает артифакты, то сможете заметить, что любая библиотека доступна во всех её версиях. Каждый раз, когда автор вносит изменения, публикуется новая версия, но старая никуда не девается. Поэтому изменений можно не бояться. Да и удаления тоже, так как, на сколько мне известно, mvnrepository не позволяет библиотеки удалять. Самое страшное, что может случиться - библиотека перестанет развиваться.

Например, процессор с частотой 2.5ГГц выполняет 2,5 миллиарда циклов. КАК?) Как люди к этому пришли?

Вы ведь знаете что такое Герц вообще? 1 Гц - одно колебание в секунду, 100 - Гц это 100 колебаний в секунду, 100 Мега Герц - 100 миллионов колебаний (FM радио в этом диапазоне работает), а 1 ГГц - в десять раз больше (миллиард).

Ну и процессоры не сразу такими шустрыми стали, ZX Spectrum (1982) работал на 3.5МГц, например. А теплый ламповый ЭНИАК (1943) работал всего на 100 кГц (сто тысяч тактов в секунду).

Как они придумали пленки для жесткого диска, что бы туда "намагничивать" нолики и единички ?)

Началось все с фонографа (1877), там были цилиндры покрытые воском или фольгой. Практически сразу начались эксперименты с магнитным слоем (первые публикации 10 лет спустя), но в массы оно не пошло - сложно, дорого, качество не очень.
Затем появились более практичные патефоны, с пластинками.

Магнитофоны с магнитными лентами параллельно развивались, но в массовое использование не попадали.
1935

Компьютеры первого поколения работали с перфокартами и перфолентами, которые ведут свою историю аж от станков Жаккарда.

Затем сообразили, что магнитные ленты удобнее и быстрее бумажных. Затем запарились крутить перемотку, и сообразили что диски (прям как в патефоне) еще удобнее - можно переставить головку на нужную дорожку. В 1973 году был выпущен жёсткий диск "винчестер" аж на целых 60 МегаБайт.

Ну и понеслась: больше плотность записи, больше скорость вращения, больше пластин, быстрее, плотнее, быстрее...

Специальный учебник не особо и нужен, если есть вики и любопытство.

Нашёл!
Автор: mindw0rk
Рассказ: Незнакомец по ту сторону сети
Рассказ не длинный.