В мире Linux — «все есть в репозиториях» — поставил из репозитория — устаревшая, кривая и не рабочая версия.
Устаревшая — это вполне вероятно. А вот чтобы кривая и нерабочая — такое редко бывает.
Скачиваешь пакет, ой, у меня же не deb/rpm/pac
А что у вас?
Собираю из исходников несколько дней.
Надо ещё проверить на предмет наличия экзешника. Например Shotcut (редактор видео такой) можно скачать в виде standalone приложения, скопировать в какую-нибудь директорию и просто запустить.
Кстати чем синглтон не угодил не очень понятно — то что теперь они рулятся через AddSingleton() фунцию в DI фреймворке ничего по сути не меняет.
Я бы сказал, что меняет вообще всё. Паттерн синглтон не столько о том, что должен быть один объект какого-то класса, сколько о том, как написать код так, чтобы второй объект было нельзя сделать.
Синглтоны в контейнере такого не навязывают. Я думаю, если бы контейнера не было, а была бы просто сборка всего контекста вручную, где объект создаётся через new один раз, а потом всем передаётся в конструктор в качестве аргумента, никто и не подумал бы называть это синглтоном.
Ну, инструмент в виде редактора у вас уже есть, плагины к нему тоже есть. Единственное что нужно сделать это прикруть вызов pandoc к какому-нибудь хоткею. Вам и с этим не хочется возиться?
Можно мне либо нормально спроектированный язык разметки, либо нормально реализованный визивиг?
Можно. Выбирайте любой язык разметки, который вам нравится, потом в своём любимом редакторе делайте таблицу. Наверняка там уже есть куча плагинов, которая делает этот процесс удобным. А потом с помощью pandoc конвертируйте в markdown. Или сразу в хабровскую версию html.
Plaintext ввод с markdown был бы куда более эргономичен.
Прочитал ваш комментарий, увидел вот это "был бы" и не понял. Ведь markdown на хабре всегда был. Проверил. И вроде он ещё есть, но его совершенно серьёзно собираются убрать навсегда. И совершенно серьёзно хотят чтобы технические специалисты писали тексты в этом самом WYSIWYG редакторе.
Я честно говоря не понимаю как так вышло. Может быть редакторам так удобнее. Не знаю.
Опять же для id это может быть не всегда верно, т.к. при создание entity поле не будет заполнено
Да, поэтому если id равен null equals должен возвращать false. Независимо от того, чему равен id другой энтити. А чтобы можно было найти сущность после появления id, нужно из hashCode всегда возвращать 31
Слов с сочетанием ЙЕ предостаточно: вуайерист, Йемен, конвейер, фейерверк и т.д.
Ну да. Иногда даже возникает ощущение, что Й тут действительно звучит. Но положа руку на сердце, я не уверен, что замечу какую-то разницу, если в этих словах Й убрать.
Слов с сочетанием ЙЭ сейчас нет ни одного.
Неудивительно, ведь для этого есть буква Е )))
У вас не возникает соблазна писать Емен и конвеер, раз уж звук Й в этих Е уже находится?
Соблазна не возникает потому, что я знаю, как пишутся эти слова. Но если бы я не знал, то наверное у меня не возникло бы желания поставить туда Й
Ну или взять Ъ. В современном русском он обозначает /й/. Почему слово /сйем/ не писать как сйем?
Мне кажется в вашем примере Ъ обозначает, что не нужно сливать согласную со следующей гласной. А звука там вообще никакого нет. Звук Й находится в букве Е. Можно было бы наверное писать сйэм.
Это будет иметь смысл если только они не будут замедлять выполнение. Обработка исключений — это дорого
Тут стоит упомянуть, что исключения это инструмент, предназначенный для использования там, где исключительные ситуации возникают редко и обрабатывать их в основном не придётся. На то они и исключительные.
весь этот метод [… ] в 50% случаев будет вылетать в oops [… ] — если он вызывается сотни миллионов раз то исключения напрочь убьют производительность.
Если в 50% случаев метод выбрасывает эксепшн, то лучше не использовать эксепшны в этом методе. В этом случае явно у нас нет исключительной ситуации, а есть один из ожидаемых исходов. Эксепшны, по крайней мере в Джаве, практически бесплатны, если возникают редко, но, как вы справедливо заметили, очень дороги, если их приходится часто обрабатывать.
Гугль хорошо описал большинство "за" и "против" и в итоге отказался от них даже в C++
По ссылке, которую вы дали в явном виде озвучен вывод гугла — в случае эксепшнов "за" перевешивают "против", то есть эксепшны это скорее хорошо, чем плохо. Гугл отказался от них из-за большого количества легаси кода.
"тащить и не пущать" — это плохая практика, это всё равно что отказаться от утюгов и стиральных машин дома и заставить людей отдавать стирать и гладить вещи в спецсервисы, а то пожары случаются
Кстати, если бы пожары и затопления случались часто — давно бы уже запретили держать дома что утюги, что стиральные машины ))
Не поймите меня неправильно, я не за повсеместное использование goto.
Да мне кажется мы друг друга отлично поняли ))
Я за то, чтобы включать голову, и писать понятный код.
А я ещё за то, чтобы делать как сделано в джаве. То есть выделить полезные применения и сделать отдельными фичами, убрав заведомо вредные варинаты использования.
В случае с С++, я бы наверное стал искать какой-нибудь линтер, который разрешает делать только хорошо. Если конечно в случае с С++ его получится написать, тут я плохо разбираюсь.
Тем не менее, я считаю, что в этих нескольких случаях применение было оправданным с точки зрения написания читаемого кода.
Не сомневаюсь. На самом деле очень любопытно, что это за случаи. То есть можно ли среди них найти какой-то новый тип использования goto, помимо известных мне.
Но не сказали, чем плоха предложенная мной конструкция.
С моей точки зрения, ответ простой. Для того, чтобы её использовать придётся затащить в язык goto, который в большинстве случаев оказывается вредным. И по итогу легче вообще убрать goto, чем следить за тем, как его использовать.
У goto я лично знаю два кейса удачного применения. Переход к концу метода в случае возникновения ошики, и тот, что продемонстрировали вы.
Первое решается введением в язык эксепшнов.
Ваш кейс, по крайней мере в джаве, будет выглядеть вот так
label:
for (int i = 0; i < w; i++) {
for (int j = 0; j < h; j++) {
if (get(i,j)) {
break label;
}
}
}
goto убрали, а полезные функции раздали другим конструкциям
Просто ваше утверждение, что 1 поток на 2 сокета справится с задачей пересылки быстрее, чем 2 потока на 2 сокета сильно интригующе и противоречит всему тому, что я читал 10 лет и моему здравому смыслу.
Если один поток обрабатывает 2 сокета, то на обработку одного секта уйдёт больше времени, чем если бы один поток работал с одним сокетом. Потому что какое-то время поток работает с другим сокетом. Это увеличивает latency.
Но суммарно на обработку двух сокетов уйдёт меньше времени, потому что пересылка данных для обоих сокетов происходит параллельно. Это увеличивает throughput.
Если мы сравниваем 1 поток обрабатывающий 2 сокета с двумя потоками, обрабатывающими 2 сокета, то latency у двух потоков будет чуть меньше, throughput будет чуть больше, но также вырастет количество используемого CPU и чуть чуть количество оперативной памяти.
Неблокирующие техники используются как раз для того, чтобы сильно сократить использование CPU и памяти при равном throughput с несущественным увеличением latency.
Насколько я помню, nio — не о throughput, а о scalability.
Ну тут именно о throughput.
Ссылок на бенчмарки сейчас по памяти не приведу, но, как минимум, переключение контекстов должно добавлять накладных расходов.
Если количество одновременных запросов больше количества потоков, то пропускная спосоность увеличивается, хотя каждый отдельный запрос может обрабатываться дольше. Как раз за счёт переключения контекстов в том числе.
Но вообще ожидание ответа или ожидание данных после установки соединения это очень долго. За это время можно успеть пару раз переключить контекст и сообщить другим соединениям, что они могут отправлять данные. И потом ещё какие-нибудь данные, полученные из третьего соединения обработать. А потом вернуться к первому соединению и проверить, пришло ли в него что-нибудь.
Да и не просто так однопоточный gc показывает более высокий именно throughput.
Не просто так, да. Потому что он специально останавливает всё, чтобы ничего не ждать, а просто перемолотить все объекты.
Зачем код простаивает после ожидания ответа (или во время?) и перед обработкой?
Программист специально так написал код. Только простававет не код, а поток в котором код исполняется.
Если хотите поискать в этом практический смысл, то когда поток ждёт ответа, он гарантировано будет не занять, когда ответ придёт и сразу сможет обработать ответ. И поэтому время на обработку одного запроса будет чуть меньше. Если количество одновременно обрабатываемых запросов всегда меньше максимального количества потоков, то такой код будет работать чуть быстрее, чем код, который не ждёт ответа.
Разве поток не может отправить другой запрос вместо простаивания?
Может, но код надо писать по другому.
Дополню, я не настоящий jav'ист, в java нельзя отправлять асинхронные запросы?
И dexamethason. Как я понял это были 2 маленькие таблетки которые мне дали вечером и в 10 утра следующего дня.
Интересно. В наших больницах дексаметазон капают через капельницу. Говорят по другому малоэффективен. Мне кололи его внутримышечно дней 6, состояние ухудшилось. После пары дней под капельницей стало лучше.
Очень ёмкие вопросы в комментарии, по поводу каждого статью наверное можно забабахать. Отвечу кратко на, с моей точки зрения, самый важный. Можно ли устроиться джуниором после курсов.
Вопрос непростой.
Да, джуниором устроиться можно, но требования к начинающему разработчику сильно зависят от компании и проекта. Мы готовим людей к разработке бекенда с использованием Spring. Компаний, использующих такой стек много, тут всё хорошо.
Кроме стека, у компании должно быть чёткое понимание, какие задачи она хочет поставить перед новым разработчиком. Если компания ищет разработчика просто на всякий случай, то скорее всего набирать будут мидлов.
И нужен ещё старший программист, который готов отвечать на вопросы, которые обязательно появятся у джуниора.
Под такое описание обычно подходят стартапы или какие-то продуктовые компании, в которых не хватает рабочих рук. Сейчас такие компании на рынке есть, главное каким-то образом обратить на себя их внимание. Придётся рассылать резюме, проходить собеседования и ждать отзывов, которые не каждая контора ещё даст. Но перспективы реальные, месяц назад по крайней мере один такой джуниор работу нашёл, с интересом за ним наблюдаю ))
Однако есть одно но. Мне в последнее время говорят, что надо всё объяснять с помощью аналогий, иначе непонятно, поэтому вот держите аналогию из мира спорта.
Когда поднимаешь тяжести, есть две составляющих успеха. Во-первых, техника. Если поднимать тяжести правильно, то результаты появятся гораздо быстрее, чем если заниматься этим как-попало.
Но если ограничиться теоретическими занятиями и отработкой техники на пустом грифе, то результат не появится никогда.
Тренер может рассказать как делать правильно. Может посмотреть, что делаете вы и дать оценку. Но для того, чтобы были результаты, нужно регулярно заниматься в тренажёрном зале. Самому. Тут тренер ничего не сделает, этим вам придётся заниматься самостоятельно.
И важно отметить, что продвинутые техники может изучить только человек, у которого уже есть какое-то минимальное количество мышечной массы, это важно.
Так и с программированием. Первые занятия у всех идут хорошо. С помощью домашних заданий мы можем проверить, поняли учащиеся материал, или нет. Но чтобы делать домашние задания для следующих занятий, нужно свободно владеть приёмами, описанными на предыдущих. Многим для этого придёся прорешать задачи дополнительно. И за них это никто не сделает.
Когда вам будут рассказывать про паттерны, это будут делать на примере кода. И нужно хорошо понимать, как работает этот код и что делает. Достичь такого понимания можно только одним способом. Писать код самостоятельно. И позже читать чужой код.
К собеседованиям тоже придётся готовиться. Если вы понимаете, как устроен динамический массив, но не можете об этом рассказать, то с точки зрения работодателя это всё равно как если вы вообще не знаете, что это такое. Придётся тренироваться отвечать перед зеркалом.
Поэтому ещё раз скажу, устроиться джуниором реально, но очень многое зависит от вас.
P. S. В роли наставника я увы, сейчас выступать не могу, курс постоянно корректируется на основе обратной связи, на это много времени уходит. Если хочется пообщаться именно со мной, пишите в личку, я обязательно отвечу.
Кому станет хуже от того, что юзер станет чаще выигрывать?
Ну как же. Тому программисту, который написал такой код, что юзер выигрывает редко )). В потом уже другой программист, которого наняли, чтобы поправить код предыдущего, переживал по этому же поводу.
Больше похоже на таракан, чем на профессиональную этику.
Таракан, да, но по мнению некоторых, такие тараканы отличают хороших программистов от идеальных ))
Это не мой некропостинг, просто кто-то прокрастинировал с одобрением комментария пять лет.
Да, я очень удивился. Не мог отказать себе в удовольствии ответить )))
цель подобных курсов всегда одна — заработать денег.
Как в общем и цель любого бизнеса )). Но как правило, когда речь о курсах, заработать денег получается только если бизнес выполняет свои обещания и курсы взаправду дают знания и скилы.
не знания продать. не научить за оплату. а именно — заработать денег.
Отдельно хочу сказать за себя. Я тут именно для того, чтобы научить программировать тех, кто этого хочет. Вопрос денег лично у меня вторичен. Мне неоднократно говорили, что это нездоровая позиция, возможно я её перерасту когда-нибудь, но пока что вот так.
за два три месяца плотных занятий, по 6...8 часов каждый день — можно выйти на уверенного джуна. и что там растягивать на 11 месяцев ??
Совершенно согласен, можно. Хотя я бы, конечно, слово максимум убрал бы )). Если есть желание и силы впахивать по 6...8 часов каждый день в течении трёх месяцев, то можно. Особенно, если готовишься к конкретной позиции в конкретной компании. Я даже знаю случаи.
Мне особенно приятно читать ваш комментарий потому, что зачастую я сталкиваюсь с обратной позицией — что для того, чтобы стать джуниором и трёх лет не всегда хватает.
Но на курсы приходят люди, которые каждый день работают и у которых полный день найдётся только на выходных и это в лучшем случае. Вот из-за этого получается 11 месяцев.
основная проблема таких курсов в том, что они обещают "очень вкусное" но трудно выполнимое. научить "для людей без бэкграунда в IT". почему же трудно выполнимое? да потому, что далеко не всем это реально интересно и нужно.
Сложно поспорить, всё именно так и есть. Именно поэтому я всегда повторяю, что ничего невозможного нет, нужно только желание и труд. Только желание по-настоящему нужно и трудиться действительно придётся. Это очень важно осознавать.
Устаревшая — это вполне вероятно. А вот чтобы кривая и нерабочая — такое редко бывает.
А что у вас?
Надо ещё проверить на предмет наличия экзешника. Например Shotcut (редактор видео такой) можно скачать в виде standalone приложения, скопировать в какую-нибудь директорию и просто запустить.
Я бы сказал, что меняет вообще всё. Паттерн синглтон не столько о том, что должен быть один объект какого-то класса, сколько о том, как написать код так, чтобы второй объект было нельзя сделать.
Синглтоны в контейнере такого не навязывают. Я думаю, если бы контейнера не было, а была бы просто сборка всего контекста вручную, где объект создаётся через new один раз, а потом всем передаётся в конструктор в качестве аргумента, никто и не подумал бы называть это синглтоном.
Ну, инструмент в виде редактора у вас уже есть, плагины к нему тоже есть. Единственное что нужно сделать это прикруть вызов pandoc к какому-нибудь хоткею. Вам и с этим не хочется возиться?
Я вас не совсем понимаю. Вам хотелось бы, чтобы для вас всё это кто-то построил?
Можно. Выбирайте любой язык разметки, который вам нравится, потом в своём любимом редакторе делайте таблицу. Наверняка там уже есть куча плагинов, которая делает этот процесс удобным. А потом с помощью pandoc конвертируйте в markdown. Или сразу в хабровскую версию html.
Прочитал ваш комментарий, увидел вот это "был бы" и не понял. Ведь markdown на хабре всегда был. Проверил. И вроде он ещё есть, но его совершенно серьёзно собираются убрать навсегда. И совершенно серьёзно хотят чтобы технические специалисты писали тексты в этом самом WYSIWYG редакторе.
Я честно говоря не понимаю как так вышло. Может быть редакторам так удобнее. Не знаю.
Да, поэтому если id равен null equals должен возвращать false. Независимо от того, чему равен id другой энтити. А чтобы можно было найти сущность после появления id, нужно из hashCode всегда возвращать 31
Ну да. Иногда даже возникает ощущение, что Й тут действительно звучит. Но положа руку на сердце, я не уверен, что замечу какую-то разницу, если в этих словах Й убрать.
Неудивительно, ведь для этого есть буква Е )))
Соблазна не возникает потому, что я знаю, как пишутся эти слова. Но если бы я не знал, то наверное у меня не возникло бы желания поставить туда Й
Мне кажется в вашем примере Ъ обозначает, что не нужно сливать согласную со следующей гласной. А звука там вообще никакого нет. Звук Й находится в букве Е. Можно было бы наверное писать сйэм.
Тут стоит упомянуть, что исключения это инструмент, предназначенный для использования там, где исключительные ситуации возникают редко и обрабатывать их в основном не придётся. На то они и исключительные.
Если в 50% случаев метод выбрасывает эксепшн, то лучше не использовать эксепшны в этом методе. В этом случае явно у нас нет исключительной ситуации, а есть один из ожидаемых исходов. Эксепшны, по крайней мере в Джаве, практически бесплатны, если возникают редко, но, как вы справедливо заметили, очень дороги, если их приходится часто обрабатывать.
По ссылке, которую вы дали в явном виде озвучен вывод гугла — в случае эксепшнов "за" перевешивают "против", то есть эксепшны это скорее хорошо, чем плохо. Гугл отказался от них из-за большого количества легаси кода.
Кстати, если бы пожары и затопления случались часто — давно бы уже запретили держать дома что утюги, что стиральные машины ))
Да мне кажется мы друг друга отлично поняли ))
А я ещё за то, чтобы делать как сделано в джаве. То есть выделить полезные применения и сделать отдельными фичами, убрав заведомо вредные варинаты использования.
В случае с С++, я бы наверное стал искать какой-нибудь линтер, который разрешает делать только хорошо. Если конечно в случае с С++ его получится написать, тут я плохо разбираюсь.
Не сомневаюсь. На самом деле очень любопытно, что это за случаи. То есть можно ли среди них найти какой-то новый тип использования goto, помимо известных мне.
С моей точки зрения, ответ простой. Для того, чтобы её использовать придётся затащить в язык goto, который в большинстве случаев оказывается вредным. И по итогу легче вообще убрать goto, чем следить за тем, как его использовать.
У goto я лично знаю два кейса удачного применения. Переход к концу метода в случае возникновения ошики, и тот, что продемонстрировали вы.
Первое решается введением в язык эксепшнов.
Ваш кейс, по крайней мере в джаве, будет выглядеть вот так
goto убрали, а полезные функции раздали другим конструкциям
Завернуть в метод и написать return
Если один поток обрабатывает 2 сокета, то на обработку одного секта уйдёт больше времени, чем если бы один поток работал с одним сокетом. Потому что какое-то время поток работает с другим сокетом. Это увеличивает latency.
Но суммарно на обработку двух сокетов уйдёт меньше времени, потому что пересылка данных для обоих сокетов происходит параллельно. Это увеличивает throughput.
Если мы сравниваем 1 поток обрабатывающий 2 сокета с двумя потоками, обрабатывающими 2 сокета, то latency у двух потоков будет чуть меньше, throughput будет чуть больше, но также вырастет количество используемого CPU и чуть чуть количество оперативной памяти.
Неблокирующие техники используются как раз для того, чтобы сильно сократить использование CPU и памяти при равном throughput с несущественным увеличением latency.
Ну тут именно о throughput.
Если количество одновременных запросов больше количества потоков, то пропускная спосоность увеличивается, хотя каждый отдельный запрос может обрабатываться дольше. Как раз за счёт переключения контекстов в том числе.
Но вообще ожидание ответа или ожидание данных после установки соединения это очень долго. За это время можно успеть пару раз переключить контекст и сообщить другим соединениям, что они могут отправлять данные. И потом ещё какие-нибудь данные, полученные из третьего соединения обработать. А потом вернуться к первому соединению и проверить, пришло ли в него что-нибудь.
Не просто так, да. Потому что он специально останавливает всё, чтобы ничего не ждать, а просто перемолотить все объекты.
Программист специально так написал код. Только простававет не код, а поток в котором код исполняется.
Если хотите поискать в этом практический смысл, то когда поток ждёт ответа, он гарантировано будет не занять, когда ответ придёт и сразу сможет обработать ответ. И поэтому время на обработку одного запроса будет чуть меньше. Если количество одновременно обрабатываемых запросов всегда меньше максимального количества потоков, то такой код будет работать чуть быстрее, чем код, который не ждёт ответа.
Может, но код надо писать по другому.
Можно.
Интересно. В наших больницах дексаметазон капают через капельницу. Говорят по другому малоэффективен. Мне кололи его внутримышечно дней 6, состояние ухудшилось. После пары дней под капельницей стало лучше.
Очень ёмкие вопросы в комментарии, по поводу каждого статью наверное можно забабахать. Отвечу кратко на, с моей точки зрения, самый важный. Можно ли устроиться джуниором после курсов.
Вопрос непростой.
Да, джуниором устроиться можно, но требования к начинающему разработчику сильно зависят от компании и проекта. Мы готовим людей к разработке бекенда с использованием Spring. Компаний, использующих такой стек много, тут всё хорошо.
Кроме стека, у компании должно быть чёткое понимание, какие задачи она хочет поставить перед новым разработчиком. Если компания ищет разработчика просто на всякий случай, то скорее всего набирать будут мидлов.
И нужен ещё старший программист, который готов отвечать на вопросы, которые обязательно появятся у джуниора.
Под такое описание обычно подходят стартапы или какие-то продуктовые компании, в которых не хватает рабочих рук. Сейчас такие компании на рынке есть, главное каким-то образом обратить на себя их внимание. Придётся рассылать резюме, проходить собеседования и ждать отзывов, которые не каждая контора ещё даст. Но перспективы реальные, месяц назад по крайней мере один такой джуниор работу нашёл, с интересом за ним наблюдаю ))
Однако есть одно но. Мне в последнее время говорят, что надо всё объяснять с помощью аналогий, иначе непонятно, поэтому вот держите аналогию из мира спорта.
Когда поднимаешь тяжести, есть две составляющих успеха. Во-первых, техника. Если поднимать тяжести правильно, то результаты появятся гораздо быстрее, чем если заниматься этим как-попало.
Но если ограничиться теоретическими занятиями и отработкой техники на пустом грифе, то результат не появится никогда.
Тренер может рассказать как делать правильно. Может посмотреть, что делаете вы и дать оценку. Но для того, чтобы были результаты, нужно регулярно заниматься в тренажёрном зале. Самому. Тут тренер ничего не сделает, этим вам придётся заниматься самостоятельно.
И важно отметить, что продвинутые техники может изучить только человек, у которого уже есть какое-то минимальное количество мышечной массы, это важно.
Так и с программированием. Первые занятия у всех идут хорошо. С помощью домашних заданий мы можем проверить, поняли учащиеся материал, или нет. Но чтобы делать домашние задания для следующих занятий, нужно свободно владеть приёмами, описанными на предыдущих. Многим для этого придёся прорешать задачи дополнительно. И за них это никто не сделает.
Когда вам будут рассказывать про паттерны, это будут делать на примере кода. И нужно хорошо понимать, как работает этот код и что делает. Достичь такого понимания можно только одним способом. Писать код самостоятельно. И позже читать чужой код.
К собеседованиям тоже придётся готовиться. Если вы понимаете, как устроен динамический массив, но не можете об этом рассказать, то с точки зрения работодателя это всё равно как если вы вообще не знаете, что это такое. Придётся тренироваться отвечать перед зеркалом.
Поэтому ещё раз скажу, устроиться джуниором реально, но очень многое зависит от вас.
P. S. В роли наставника я увы, сейчас выступать не могу, курс постоянно корректируется на основе обратной связи, на это много времени уходит. Если хочется пообщаться именно со мной, пишите в личку, я обязательно отвечу.
Ну как же. Тому программисту, который написал такой код, что юзер выигрывает редко )). В потом уже другой программист, которого наняли, чтобы поправить код предыдущего, переживал по этому же поводу.
Таракан, да, но по мнению некоторых, такие тараканы отличают хороших программистов от идеальных ))
Да, я очень удивился. Не мог отказать себе в удовольствии ответить )))
Как в общем и цель любого бизнеса )). Но как правило, когда речь о курсах, заработать денег получается только если бизнес выполняет свои обещания и курсы взаправду дают знания и скилы.
Отдельно хочу сказать за себя. Я тут именно для того, чтобы научить программировать тех, кто этого хочет. Вопрос денег лично у меня вторичен. Мне неоднократно говорили, что это нездоровая позиция, возможно я её перерасту когда-нибудь, но пока что вот так.
Совершенно согласен, можно. Хотя я бы, конечно, слово максимум убрал бы )). Если есть желание и силы впахивать по 6...8 часов каждый день в течении трёх месяцев, то можно. Особенно, если готовишься к конкретной позиции в конкретной компании. Я даже знаю случаи.
Мне особенно приятно читать ваш комментарий потому, что зачастую я сталкиваюсь с обратной позицией — что для того, чтобы стать джуниором и трёх лет не всегда хватает.
Но на курсы приходят люди, которые каждый день работают и у которых полный день найдётся только на выходных и это в лучшем случае. Вот из-за этого получается 11 месяцев.
Сложно поспорить, всё именно так и есть. Именно поэтому я всегда повторяю, что ничего невозможного нет, нужно только желание и труд. Только желание по-настоящему нужно и трудиться действительно придётся. Это очень важно осознавать.