Я бы отнес стремление к минимальному размеру страничку уже к оптимизации.
Да, это важно пользователю, но, как показывает практика, бизнесу это не особо важно, бизнес воспринимает оптимизации как лишние затраты ресурсов, и без серьезной причины заниматься ими не станет.
Проблема в том, что оптимизациями мало кто занимается. Обычно как: дизайнеры навалили идей, бизнес обрадовался, на страничку навалили тонну графики, видео, эффектов, раздули размер до 20-40мб и больше, проверили что она загружается на современном топовом железе, находясь в столице, прямо рядом с датацентром, и на этом все. Руководство бежит делать презентации, ну а остальное никому не интересно.
Никому даже не приходит в голову проверить как это будет работать откуда-нибудь за тысячу км или с мобильного интернета в условия плохой связи. Да и наверное не интересно: основная доля клиентов как правило в столицах, а там со связью все хорошо.
Определенная доля истины в этом есть, причем не только для регулярок. На самом деле гибридный подход мало где упоминают, но в некоторых случаях он невероятно эффективен, и является единственным адекватным решением.
В моей практике был такой случай: медленный огромный динамический запрос в БД, из-за которого вешалась одна из подсистем сервиса, и который не удалось победить в рамках SQL или кеширования, но в итоге удалось забороть именно гибридным подходом, с промежуточными вычислениями в коде.
Ребята в течении трех лет несколько раз пытались оптимизировать проблемный запрос, но ничего сделать не смогли, и в итоге просто сдались, отказавшись от любых дальнейших попыток. Но в рамках не связанной напрямую с проблемой задачи эта проблема случайно досталась и мне, в стиле "просто посмотреть, вдруг что-то можно сделать". И за пару дней мозгового штурма и анализа мне тоже не удалось его существенно ускорить в рамках SQL, хотя запрос и был препарирован до мельчайших частей, тщательно изучен, многократно проанализирован и пересобран около 2-3 десятков раз в различных вариантах, разными методами и способами, от базовых до самых извращенных - это уже был спортивный интерес. В итоге только подтвердил выводы ребят: в рамках SQL и ограничений системы тут ничего не сделать, в любом случае каждый раз БД приходится перемалывать огромные объемы данных, откуда и идет большая задержка, и для функционала запроса нужен весь этот объем данных.
Такое обычно решается кешированием, но из-за динамического характера запроса кеширование тут не прикрутить никаким боком: каждый результат работы уникален, как и набор условий - таково желание бизнеса, что поделать. В общем так и мучались ребята годами, между молотом и наковальней.
Мне же пришло в голову декомпозировать не сам запрос, а задачу решаемую им в целом - там и удалось нащупать гибридное решение. Причем сначала просто как идею, а потом ее удалось развить и в полноценное решение проблемы.
В чем суть: Да, сам запрос уникален, динамический, и с этим ничего не сделать. Но его можно распилить на несколько запросов, и можно часть входных и промежуточных данных сгруппировать и выделить из них статическую, в рамках ограниченного набора условий, часть - это значительно снизит объем перемалываемых в последней части запроса данных в БД, т.к. условия фактически уже предвычесленны и оптимизированы. Причем без какой-либо потери функционала. Но с существенным замедлением работы: теперь имеем несколько запросов вместо одного. В общем это шаг назад. Видимо из-за этого такой вариант ранее никто и не рассматривал: задача ускорить, а не замедлить.
Но тут как с денормализацией БД: иногда нужно сделать шаг назад, чтобы прыгнуть вперед. Из-за того, что появились статические условия, пусть и в рамках ограниченного набора условий, появилась возможность начальные части запроса поместить в кеши - теперь для этого не нужны бесконечные кеши под каждый вызов, теперь это всего несколько десятков вариантов наборов условий, которые отлично кешируются. Конечно кеширование тоже пришлось оптимизировать - объем данных там хоть и относительно небольшой, но заметный, пришлось выгружать два примитивных поля в отдельные кеши, с промежуточным сжатием, т.к. на таких объемах без сжатия задержку начинает давать уже кеш. А динамическая часть запроса при этом никуда не делась, просто теперь она дополняется кешированными предвычесленными данными, и по БД фактически остается перебрать совсем немного данных.
В результате запрос удалось ускорить на два порядка - ответы сервиса стали почти мгновенными. При этом работает кеш, и запрос так и остался динамическим - каждый раз использует уникальные условия и отдает разные данные. Из-за такого ускорения даже появилась возможность для более сложных условий - самую тяжелую часть удалось вынести в кеши.
Конечно задача сама по себе упорота, и тут скорее сыграл спортивный интерес, но факт в том, что в таких случаях помогает только гибридный подход к оптимизации, в рамках какой-то отдельной области/инструмента задача в принципе нерешаема. Но тут нужно аккуратно приложить мозг, взвесить все за и против - не всегда овчинка стоит выделки, как минимум такое решение значительно сложнее любого другого, в том числе по затратам времени и усилий, это уже глубокая оптимизация получается.
Действительно, это обычная оптимизация. И вариантов ее провести множество, от извращений с низкоуровневой обработкой внутри языка, до частичного или полного выноса задачи во внешнюю библиотеку/утилиту, написанную хоть на ассемблере.
Для того специалисту и нужен опыт, чтобы оценить задачу и выбрать оптимальное решение, с учетом требований, ресурсов и возможностей.
Если прям совсем жесткие требования по производительности и огромный поток данных, оптимизация заходит еще дальше - фирмы заказывают специализированную железную логику под свои задачи, выносят задачи на аппаратные ускорители. С точки зрения младшего специалиста это выглядит как лютые костыли: вместо красивого гибкого кода прикручивают жесткую логику и получают большой гемморой с любыми дальнейшими изменениями. Но такова цена оптимизаций: оптимизации - это необходимость, это компромисс, это боль, это не про красивый код.
Такое обычно решается на уровне старших специалистов: сеньоров/техлидов/архитекторов. У младших от таких задач происходит преждевременное зажигание: слишком много всего учитывать нужно и часто приседать, мозг включать нужно в конце концов, к такому жизнь их не готовила. Но если с планированием в организации проблемы, такое может достаться даже джуну, и тут как минимум нужно идти пинать старшего - он расскажет как лучше всего решить задачу, или, если видит что задача явно не по плечам младшему, просто поручит задачу кому-нибудь более опытному или заберет себе.
Очевидно что волна IT-миграции далеко не последняя. У каждого свой порог устойчивости, но каждый подобный эпизод, вызывающий панику, будет срывать новые лавины специалистов, которых в ближайшее десятилетие фактически даже заменить будет просто некем. А что ждет IT-компании... Перспективы в отрасли не особо хорошие просматриваются.
Как минимум сложность в том, что задача системы образования не в выращивании специалистов. И что-то тут поменять в принципе очень сложная, практически нерешаемая, задача.
В большинстве вузов не пытаются готовить профессионалов, которые смогут работать специалистами сразу после выпуска. Это слишком сложная и комплексная задача, которая большинству учебных заведений, за исключением самых топовых, просто не под силу даже в теории (по крайней мере, в рамках традиционного подхода к обучению). Поэтому преподаватели делают лишь то, что могут — предоставляют студентам широкий спектр общей информации и прививают умение запоминать и обрабатывать данные. Навык ценный, но применять его для обучения самой профессии придется уже самостоятельно.
Когда вы придете на работу, вас спросят о том, что вы уже умеете делать, а не чему вас учили. Вашего начальника будет интересовать, что вы знаете и умеете из навыков, востребованных на должности, на которую вы претендуете.
Поэтому большинству выпускников учиться непосредственно профессии, получению диплома с названием которой они посвятили около пяти лет жизни, приходится уже после окончания университета. На первой работе, найти которую тоже будет совсем не просто. Хотя казалось бы, именно вуз — это место, где вчерашних школьников делают профессионалами. Тогда почему в жизни получается по-другому?
В жизни и на работе во главе угла всегда стоит результат, достижения которого нужно добиваться практическими действиями. А знание теории не стоит почти ничего без практики. Именно в этом одна из самых слабых сторон современного высшего образования — фундаментом программы любого вуза является преподавание теории, применять которую студентам нужно будет уже самостоятельно. Именно поэтому блестящие студенты, закончившие вуз с отличными оценками, в жизни часто не добиваются заметных результатов. Значение в жизни имеет только практика. Чем больше у вас знаний в ущерб навыкам, тем меньше от них толку. Огромный багаж теории, которая никак не применяется на практике, в реальной жизни часто оказывается пассивом, тянущим вас вниз.
Но даже теория, на которую традиционное образование неизбежно делает акцент, зачастую оказывается далеко не лучшего качества. Так уж устроен мир, что теория следует за практикой, а не наоборот. Поэтому знания, которые преподают в университетах, часто бывают не первой свежести, особенно вузах, которые откровенно не претендуют на топ лучших учебных заведений мира. Преподаватели, самые успешные из которых большую часть собственной карьеры занимались развитием навыка обучения студентов, а не самой профессией, которую они преподают, не имеют и не могут иметь той глубины знаний, которая есть у опытного и востребованного на рынке профессионала-практика.
Желание что-то тут поменять конечно похвально. Но оно разбивается о реальность: попробуйте управлять хотя бы пятью сотнями человек, и все типичные проблемы бюрократии всплывут на поверхность. Большие системы намного менее эффективны, и, чтобы хотя-бы как-то работать, должны обладать огромной избыточностью. Инерция их огромна, высокая реактивность по отношению к любым изменениям и нововведениям - это огромное плотное липкое желе, которое надежно остановит и поглотит любые ваши порывы и инициативы. Так что выстроить тут что-то эффективное - в принципе очень сложная задача, успеха добиваются единицы. Изменения приходится протаскивать годами, упорно и постепенно подавляя активное сопротивление на местах по всей системе сразу. Неблагодарная работа: на ваш искренний порыв сделать всем лучше, сэкономить много сил, времени, ресурсов, вас в лучшем случае поливают грязью, каждый день сопротивляясь любым улучшениям.
Да и потом: волшебной пилюли тут нет. Нет того единственного правильного решения, после которого все станет замечательно. Все это достигается десятилетиями успешных, не особо успешных, а иногда и откровенно провальных, попыток внедрения различных подходов - система живет и постоянно меняется, иногда в лучшую сторону, иногда в худшую. Тут задача совсем не в постройке эффективной системы образования: никто надежного рабочего рецепта не даст - его просто не существует в природе. Тут задача вырастить эффективную систему образования, что сейчас, хочется верить, и происходит. И неудачи - это тоже часть развития. А будет ли когда-нибудь достигнута желаемая цель никому неизвестно. Вполне возможно что нет: развитие нельзя остановить, даже если результат вас уже устраивает, развитие продолжится дальше, отдаляя вас от желаемого результата, чтобы приблизить к нему уже в будущем - развитие циклично.
За 10 лет трижды с таким сталкивался. Дважды помогла простая чистка контактов, третий случай - реальный выход из строя чипа памяти. Поэтому после мемтеста в первую очередь нужно прочищать контакты.
Также пару раз сталкивался с аналогичными эффектами по вине сата-кабеля. Портились файлы на дисках. Как это работает её знаю, но степень расшатанности разъема на кабеле играет роль. Поэтому при апгрейдах старые сата-кабели не переиспользую, стараюсь ставить новые кабели под новое железо, чтобы не играть в детектива в очередной раз.
Эта карточка прикидывается домашним кинотеартом. Слушал, интересный эффект получается, как в виртуальной комнате. В играх и фильмах звучит здорово.
Но не без недостатков: нет многоканального выхода, только под наушники все это заточено. Есть аналогичная X4 со всеми этими плюшками, и с многоканальным выходом, но почему-то без аппаратных эффектов, только через драйвер.
Думаю будет интересно тем, у кого все ещё нет многоканальной акустики, но хочется ее слушать. При наличии такой акустики все эти виртуальные 3D-эффекты особо не нужны.
Ещё стримерам зайдет - неплохой встроенный функционал для микрофона. Оценят регулятор голос/звук, алгоритмы очистки голоса и вырезания шумов, пресеты для подчеркивания деталей голоса, басы можно добавить, четкость речи поправить, и т.п., и даже есть аппаратный эффект для изменения голоса, чтобы на стримах говорить чужими голосами.
А каким образом разработчик может бездельничать? Он же постоянно в работе - постоянно какие-то новые задачи, которые не на пустом месте появились, решения которых кто-то очень ждет. Или речь не про разработчиков?
Пиши программы, каждая из которых делает ровно одну вещь и делает ее хорошо. Пиши программы так, чтобы было удобно использовать их вместе. Пиши программы для обработки текстовых потоков, так как это универсальный интерфейс.
Да это же по сути основные принципы проектирования современного софта и телекоммуникаций. Пиши функции так, чтобы каждая из них делала ровно одну вещь, и была по возможности чистой. Принцип тестируемости кода: чистый код легко тестировать, у него нет скрытых зависимостей, вызывающих неожиданное поведение и побочные эффекты. Принцип, без которого разработка быстро превращается в боль, в ежедневный нудный детектив. Принцип, призывающий максимально развязывать зависимости и жестко ограничивать сферу ответственности каждого фрагмента кода. Призывающий превратить код в набор стандартных кирпичиков, каждый из которых можно проверить отдельно, призывающий собирать софт только из проверенных надежных кирпичиков, что превращает задачу в детский конструктор. А еще независимые кирпичики можно и разрабатывать независимо, когда есть спецификация, что невероятно ускоряет разработку. Основные протоколы связи в сети сейчас текстовые, текстовые конфиги, текстовые сообщения, логи. По большей части сейчас человечество использует текстовые протоколы, иногда со сжатием. И совсем не из соображений эффективности, а скорее из соображений ремонтопригодности: софт и так слишком сложен, сложность нужно снижать, сложность это дорого, это время, ресурсы, энергия.
Для специфичных штук не ищут, а выращивают. На проекте можно накрутить что угодно, но сходу с этим разберется только тот, кто все это накручивал, остальные будут долго въезжать что это, как устроено, для чего и почему именно так, а также прощупывать старательно разложенные предыдущими поколениями минно полями всяческих костылей.
Если все позитивные изменения саботирует само руководство, какой смысл тратить силы и время на это подчинённым? Никакого. Это даже не их сфера ответственности.
Руководство - лучший и главный фильтр негатива в компании. Поэтому когда этот негатив есть - он там надолго. В таких случаях надо просто уходить, договориться тут не получится, т.к. не ты первый, не ты последний. Таких ходоков с предложениями всегда много, и если за несколько лет это ни к чему не привело, то и для дальнейших позитивных изменений никаких предпосылок просто нет.
Меняют не компании, а руководство. И если сама компания с этим не справляется - приходится это делать подчинённым самостоятельно, теми методами что им доступны: менять саму компанию вместе с руководством. Люди просто голосуют увольнениями, когда не могут ничего изменить, текучка это серьезный индикатор здоровья компании.
Как правило другими методами руководство не поменять - оно всегда зубами держится за кресло, принцип Питера в действии. Рядовые сотрудники в этом плане гораздо более мобильны, и могут просто менять компании.
На самом деле айти штука сложная, что бы там на курсах не расписывали.
Там в фундаменте слишком много абстрактных базовых концепций, которые нужно понимать, независимо от языка и специализации. Грубо говоря все что связано с айти - это компьютеры и алгоритмы, и это везде, и с этим нужно работать, и пусть на каком-то минимальном уровне, но понимать что там и как устроено и работает, иначе труд будет очень неэффективный и тяжелый.
Новички из других сфер приходят на курсы толпами, и никого из них этим базовым концепциям просто не обучают, потому что пласт знаний там хоть и простой, но обширный.
Их просто бросают в воду, за их же деньги, а там кто выплывет, а кто нет.
У многих принципиально нет желания учиться, есть убеждение что оплачивая курс они покупают профессию, чего естественно не происходит - такие часто бросают или делают возвраты. Ну потому что насильно обучить человека в принципе невозможно.
Остальные через боль продвигаются до какого-то уровня, и тоже бросают, просто потому что получают сплошной негатив. Кто-то распыляется, тратит силы и время на все сразу, получая на выхлопе ничего. Кто-то наоборот, пытается отхватить кусок побольше и давится, не вывозя. Им же никто не объяснял все это с точки зрения психологии, что нужно брать небольшие задачи, которые точно тебе по силам, чтобы постоянно шла позитивная подпитка от завершенных дел и решенных проблем, чтобы прогресс ощущался и мотивировал двигаться дальше, а не вот это вот все мракобесие что там наблюдается.
Кому-то везет и все дается легко. Может быть технический склад ума и темы близкие, а может школа/вузы подготовили, заложили какую-то часть фундамента: та же информатика много где есть.
Кто-то уже через пару месяцев на стажировке, и у них на прикладных задачах прогресс прет быстрее всех. А кто-то уже несколько лет в ленивом режиме проходит второй-третий курс, забывая предыдущее без практики.
Ну а большинство просто отваливаются уже на этом этапе. Интерес же к этой теме есть не у всех, а без интереса мотивация слабая. Некоторые потом возвращаются через год-два, иногда второй, третий раз, и часть из них даже рано или поздно все равно вливается.
Но не всем везет дойти до конца, тут ничего не поделать. Учеба - это тоже вполне себе серьезный труд.
Хорошо к этому подходят уже те, кто четко знает зачем они учатся, у кого есть твердая цель. Как правило это люди уже около 30-40, имеющие пару профессий за плечами, и четко осознающие зачем им айти, готовые ради своей цели на определенные жертвы, готовые тратить на это время, деньги, усилия, имеющие какую-никакую дисциплину и целеустремленность. Такие с самых первых дней на новой должности привлекают к себе внимание: они цельные, они ответственные, они усвоили свой объем знаний, на них можно положиться, они умеют общаться с людьми, через многое прошли, и боятся им в принципе уже нечего - все это прям неплохой такой трамплин в начале новой карьеры.
Каким образом? Оно оффлайн
Совсем не складывается. Тут именно совместный доступ к коду их обязали порезать. А вот в чем смысл такого принуждения - пока непонятно.
В отличии от других организаций, jetbrains четко показывают, что решение вынужденное, рубить бизнес больше необходимого им интереса нет.
Я бы отнес стремление к минимальному размеру страничку уже к оптимизации.
Да, это важно пользователю, но, как показывает практика, бизнесу это не особо важно, бизнес воспринимает оптимизации как лишние затраты ресурсов, и без серьезной причины заниматься ими не станет.
Проблема в том, что оптимизациями мало кто занимается. Обычно как: дизайнеры навалили идей, бизнес обрадовался, на страничку навалили тонну графики, видео, эффектов, раздули размер до 20-40мб и больше, проверили что она загружается на современном топовом железе, находясь в столице, прямо рядом с датацентром, и на этом все. Руководство бежит делать презентации, ну а остальное никому не интересно.
Никому даже не приходит в голову проверить как это будет работать откуда-нибудь за тысячу км или с мобильного интернета в условия плохой связи. Да и наверное не интересно: основная доля клиентов как правило в столицах, а там со связью все хорошо.
Определенная доля истины в этом есть, причем не только для регулярок. На самом деле гибридный подход мало где упоминают, но в некоторых случаях он невероятно эффективен, и является единственным адекватным решением.
В моей практике был такой случай: медленный огромный динамический запрос в БД, из-за которого вешалась одна из подсистем сервиса, и который не удалось победить в рамках SQL или кеширования, но в итоге удалось забороть именно гибридным подходом, с промежуточными вычислениями в коде.
Ребята в течении трех лет несколько раз пытались оптимизировать проблемный запрос, но ничего сделать не смогли, и в итоге просто сдались, отказавшись от любых дальнейших попыток. Но в рамках не связанной напрямую с проблемой задачи эта проблема случайно досталась и мне, в стиле "просто посмотреть, вдруг что-то можно сделать". И за пару дней мозгового штурма и анализа мне тоже не удалось его существенно ускорить в рамках SQL, хотя запрос и был препарирован до мельчайших частей, тщательно изучен, многократно проанализирован и пересобран около 2-3 десятков раз в различных вариантах, разными методами и способами, от базовых до самых извращенных - это уже был спортивный интерес. В итоге только подтвердил выводы ребят: в рамках SQL и ограничений системы тут ничего не сделать, в любом случае каждый раз БД приходится перемалывать огромные объемы данных, откуда и идет большая задержка, и для функционала запроса нужен весь этот объем данных.
Такое обычно решается кешированием, но из-за динамического характера запроса кеширование тут не прикрутить никаким боком: каждый результат работы уникален, как и набор условий - таково желание бизнеса, что поделать. В общем так и мучались ребята годами, между молотом и наковальней.
Мне же пришло в голову декомпозировать не сам запрос, а задачу решаемую им в целом - там и удалось нащупать гибридное решение. Причем сначала просто как идею, а потом ее удалось развить и в полноценное решение проблемы.
В чем суть: Да, сам запрос уникален, динамический, и с этим ничего не сделать. Но его можно распилить на несколько запросов, и можно часть входных и промежуточных данных сгруппировать и выделить из них статическую, в рамках ограниченного набора условий, часть - это значительно снизит объем перемалываемых в последней части запроса данных в БД, т.к. условия фактически уже предвычесленны и оптимизированы. Причем без какой-либо потери функционала. Но с существенным замедлением работы: теперь имеем несколько запросов вместо одного. В общем это шаг назад. Видимо из-за этого такой вариант ранее никто и не рассматривал: задача ускорить, а не замедлить.
Но тут как с денормализацией БД: иногда нужно сделать шаг назад, чтобы прыгнуть вперед. Из-за того, что появились статические условия, пусть и в рамках ограниченного набора условий, появилась возможность начальные части запроса поместить в кеши - теперь для этого не нужны бесконечные кеши под каждый вызов, теперь это всего несколько десятков вариантов наборов условий, которые отлично кешируются. Конечно кеширование тоже пришлось оптимизировать - объем данных там хоть и относительно небольшой, но заметный, пришлось выгружать два примитивных поля в отдельные кеши, с промежуточным сжатием, т.к. на таких объемах без сжатия задержку начинает давать уже кеш. А динамическая часть запроса при этом никуда не делась, просто теперь она дополняется кешированными предвычесленными данными, и по БД фактически остается перебрать совсем немного данных.
В результате запрос удалось ускорить на два порядка - ответы сервиса стали почти мгновенными. При этом работает кеш, и запрос так и остался динамическим - каждый раз использует уникальные условия и отдает разные данные. Из-за такого ускорения даже появилась возможность для более сложных условий - самую тяжелую часть удалось вынести в кеши.
Конечно задача сама по себе упорота, и тут скорее сыграл спортивный интерес, но факт в том, что в таких случаях помогает только гибридный подход к оптимизации, в рамках какой-то отдельной области/инструмента задача в принципе нерешаема. Но тут нужно аккуратно приложить мозг, взвесить все за и против - не всегда овчинка стоит выделки, как минимум такое решение значительно сложнее любого другого, в том числе по затратам времени и усилий, это уже глубокая оптимизация получается.
Действительно, это обычная оптимизация. И вариантов ее провести множество, от извращений с низкоуровневой обработкой внутри языка, до частичного или полного выноса задачи во внешнюю библиотеку/утилиту, написанную хоть на ассемблере.
Для того специалисту и нужен опыт, чтобы оценить задачу и выбрать оптимальное решение, с учетом требований, ресурсов и возможностей.
Если прям совсем жесткие требования по производительности и огромный поток данных, оптимизация заходит еще дальше - фирмы заказывают специализированную железную логику под свои задачи, выносят задачи на аппаратные ускорители. С точки зрения младшего специалиста это выглядит как лютые костыли: вместо красивого гибкого кода прикручивают жесткую логику и получают большой гемморой с любыми дальнейшими изменениями. Но такова цена оптимизаций: оптимизации - это необходимость, это компромисс, это боль, это не про красивый код.
Такое обычно решается на уровне старших специалистов: сеньоров/техлидов/архитекторов. У младших от таких задач происходит преждевременное зажигание: слишком много всего учитывать нужно и часто приседать, мозг включать нужно в конце концов, к такому жизнь их не готовила. Но если с планированием в организации проблемы, такое может достаться даже джуну, и тут как минимум нужно идти пинать старшего - он расскажет как лучше всего решить задачу, или, если видит что задача явно не по плечам младшему, просто поручит задачу кому-нибудь более опытному или заберет себе.
Очевидно что волна IT-миграции далеко не последняя. У каждого свой порог устойчивости, но каждый подобный эпизод, вызывающий панику, будет срывать новые лавины специалистов, которых в ближайшее десятилетие фактически даже заменить будет просто некем. А что ждет IT-компании... Перспективы в отрасли не особо хорошие просматриваются.
Как минимум сложность в том, что задача системы образования не в выращивании специалистов. И что-то тут поменять в принципе очень сложная, практически нерешаемая, задача.
В большинстве вузов не пытаются готовить профессионалов, которые смогут работать специалистами сразу после выпуска. Это слишком сложная и комплексная задача, которая большинству учебных заведений, за исключением самых топовых, просто не под силу даже в теории (по крайней мере, в рамках традиционного подхода к обучению). Поэтому преподаватели делают лишь то, что могут — предоставляют студентам широкий спектр общей информации и прививают умение запоминать и обрабатывать данные. Навык ценный, но применять его для обучения самой профессии придется уже самостоятельно.
Когда вы придете на работу, вас спросят о том, что вы уже умеете делать, а не чему вас учили. Вашего начальника будет интересовать, что вы знаете и умеете из навыков, востребованных на должности, на которую вы претендуете.
Поэтому большинству выпускников учиться непосредственно профессии, получению диплома с названием которой они посвятили около пяти лет жизни, приходится уже после окончания университета. На первой работе, найти которую тоже будет совсем не просто. Хотя казалось бы, именно вуз — это место, где вчерашних школьников делают профессионалами. Тогда почему в жизни получается по-другому?
В жизни и на работе во главе угла всегда стоит результат, достижения которого нужно добиваться практическими действиями. А знание теории не стоит почти ничего без практики. Именно в этом одна из самых слабых сторон современного высшего образования — фундаментом программы любого вуза является преподавание теории, применять которую студентам нужно будет уже самостоятельно. Именно поэтому блестящие студенты, закончившие вуз с отличными оценками, в жизни часто не добиваются заметных результатов. Значение в жизни имеет только практика. Чем больше у вас знаний в ущерб навыкам, тем меньше от них толку. Огромный багаж теории, которая никак не применяется на практике, в реальной жизни часто оказывается пассивом, тянущим вас вниз.
Но даже теория, на которую традиционное образование неизбежно делает акцент, зачастую оказывается далеко не лучшего качества. Так уж устроен мир, что теория следует за практикой, а не наоборот. Поэтому знания, которые преподают в университетах, часто бывают не первой свежести, особенно вузах, которые откровенно не претендуют на топ лучших учебных заведений мира. Преподаватели, самые успешные из которых большую часть собственной карьеры занимались развитием навыка обучения студентов, а не самой профессией, которую они преподают, не имеют и не могут иметь той глубины знаний, которая есть у опытного и востребованного на рынке профессионала-практика.
Желание что-то тут поменять конечно похвально. Но оно разбивается о реальность: попробуйте управлять хотя бы пятью сотнями человек, и все типичные проблемы бюрократии всплывут на поверхность. Большие системы намного менее эффективны, и, чтобы хотя-бы как-то работать, должны обладать огромной избыточностью. Инерция их огромна, высокая реактивность по отношению к любым изменениям и нововведениям - это огромное плотное липкое желе, которое надежно остановит и поглотит любые ваши порывы и инициативы. Так что выстроить тут что-то эффективное - в принципе очень сложная задача, успеха добиваются единицы. Изменения приходится протаскивать годами, упорно и постепенно подавляя активное сопротивление на местах по всей системе сразу. Неблагодарная работа: на ваш искренний порыв сделать всем лучше, сэкономить много сил, времени, ресурсов, вас в лучшем случае поливают грязью, каждый день сопротивляясь любым улучшениям.
Да и потом: волшебной пилюли тут нет. Нет того единственного правильного решения, после которого все станет замечательно. Все это достигается десятилетиями успешных, не особо успешных, а иногда и откровенно провальных, попыток внедрения различных подходов - система живет и постоянно меняется, иногда в лучшую сторону, иногда в худшую. Тут задача совсем не в постройке эффективной системы образования: никто надежного рабочего рецепта не даст - его просто не существует в природе. Тут задача вырастить эффективную систему образования, что сейчас, хочется верить, и происходит. И неудачи - это тоже часть развития. А будет ли когда-нибудь достигнута желаемая цель никому неизвестно. Вполне возможно что нет: развитие нельзя остановить, даже если результат вас уже устраивает, развитие продолжится дальше, отдаляя вас от желаемого результата, чтобы приблизить к нему уже в будущем - развитие циклично.
За 10 лет трижды с таким сталкивался. Дважды помогла простая чистка контактов, третий случай - реальный выход из строя чипа памяти. Поэтому после мемтеста в первую очередь нужно прочищать контакты.
Также пару раз сталкивался с аналогичными эффектами по вине сата-кабеля. Портились файлы на дисках. Как это работает её знаю, но степень расшатанности разъема на кабеле играет роль. Поэтому при апгрейдах старые сата-кабели не переиспользую, стараюсь ставить новые кабели под новое железо, чтобы не играть в детектива в очередной раз.
Это во всех госах такое? У коммерсов проще: кто не работает - тот не ест.
Эта карточка прикидывается домашним кинотеартом. Слушал, интересный эффект получается, как в виртуальной комнате. В играх и фильмах звучит здорово.
Но не без недостатков: нет многоканального выхода, только под наушники все это заточено. Есть аналогичная X4 со всеми этими плюшками, и с многоканальным выходом, но почему-то без аппаратных эффектов, только через драйвер.
Думаю будет интересно тем, у кого все ещё нет многоканальной акустики, но хочется ее слушать. При наличии такой акустики все эти виртуальные 3D-эффекты особо не нужны.
Ещё стримерам зайдет - неплохой встроенный функционал для микрофона. Оценят регулятор голос/звук, алгоритмы очистки голоса и вырезания шумов, пресеты для подчеркивания деталей голоса, басы можно добавить, четкость речи поправить, и т.п., и даже есть аппаратный эффект для изменения голоса, чтобы на стримах говорить чужими голосами.
А каким образом разработчик может бездельничать? Он же постоянно в работе - постоянно какие-то новые задачи, которые не на пустом месте появились, решения которых кто-то очень ждет. Или речь не про разработчиков?
Хороший пример отечественного ПО. Вполне функционально, качественно, ящитаю.
Интересный термин. Возьму на заметку
Да это же по сути основные принципы проектирования современного софта и телекоммуникаций.
Пиши функции так, чтобы каждая из них делала ровно одну вещь, и была по возможности чистой. Принцип тестируемости кода: чистый код легко тестировать, у него нет скрытых зависимостей, вызывающих неожиданное поведение и побочные эффекты. Принцип, без которого разработка быстро превращается в боль, в ежедневный нудный детектив. Принцип, призывающий максимально развязывать зависимости и жестко ограничивать сферу ответственности каждого фрагмента кода. Призывающий превратить код в набор стандартных кирпичиков, каждый из которых можно проверить отдельно, призывающий собирать софт только из проверенных надежных кирпичиков, что превращает задачу в детский конструктор. А еще независимые кирпичики можно и разрабатывать независимо, когда есть спецификация, что невероятно ускоряет разработку.
Основные протоколы связи в сети сейчас текстовые, текстовые конфиги, текстовые сообщения, логи. По большей части сейчас человечество использует текстовые протоколы, иногда со сжатием. И совсем не из соображений эффективности, а скорее из соображений ремонтопригодности: софт и так слишком сложен, сложность нужно снижать, сложность это дорого, это время, ресурсы, энергия.
Для специфичных штук не ищут, а выращивают. На проекте можно накрутить что угодно, но сходу с этим разберется только тот, кто все это накручивал, остальные будут долго въезжать что это, как устроено, для чего и почему именно так, а также прощупывать старательно разложенные предыдущими поколениями минно полями всяческих костылей.
Оно того стоит. А зарплата - зарплата быстро вырастет. У меня за два года выросла в 6 раз
А самое главное упущено: формы на госуслугах нет.
Если все позитивные изменения саботирует само руководство, какой смысл тратить силы и время на это подчинённым? Никакого. Это даже не их сфера ответственности.
Руководство - лучший и главный фильтр негатива в компании. Поэтому когда этот негатив есть - он там надолго. В таких случаях надо просто уходить, договориться тут не получится, т.к. не ты первый, не ты последний. Таких ходоков с предложениями всегда много, и если за несколько лет это ни к чему не привело, то и для дальнейших позитивных изменений никаких предпосылок просто нет.
Меняют не компании, а руководство. И если сама компания с этим не справляется - приходится это делать подчинённым самостоятельно, теми методами что им доступны: менять саму компанию вместе с руководством. Люди просто голосуют увольнениями, когда не могут ничего изменить, текучка это серьезный индикатор здоровья компании.
Как правило другими методами руководство не поменять - оно всегда зубами держится за кресло, принцип Питера в действии. Рядовые сотрудники в этом плане гораздо более мобильны, и могут просто менять компании.
Остальные сгорают.
На самом деле айти штука сложная, что бы там на курсах не расписывали.
Там в фундаменте слишком много абстрактных базовых концепций, которые нужно понимать, независимо от языка и специализации. Грубо говоря все что связано с айти - это компьютеры и алгоритмы, и это везде, и с этим нужно работать, и пусть на каком-то минимальном уровне, но понимать что там и как устроено и работает, иначе труд будет очень неэффективный и тяжелый.
Новички из других сфер приходят на курсы толпами, и никого из них этим базовым концепциям просто не обучают, потому что пласт знаний там хоть и простой, но обширный.
Их просто бросают в воду, за их же деньги, а там кто выплывет, а кто нет.
У многих принципиально нет желания учиться, есть убеждение что оплачивая курс они покупают профессию, чего естественно не происходит - такие часто бросают или делают возвраты. Ну потому что насильно обучить человека в принципе невозможно.
Остальные через боль продвигаются до какого-то уровня, и тоже бросают, просто потому что получают сплошной негатив. Кто-то распыляется, тратит силы и время на все сразу, получая на выхлопе ничего. Кто-то наоборот, пытается отхватить кусок побольше и давится, не вывозя. Им же никто не объяснял все это с точки зрения психологии, что нужно брать небольшие задачи, которые точно тебе по силам, чтобы постоянно шла позитивная подпитка от завершенных дел и решенных проблем, чтобы прогресс ощущался и мотивировал двигаться дальше, а не вот это вот все мракобесие что там наблюдается.
Кому-то везет и все дается легко. Может быть технический склад ума и темы близкие, а может школа/вузы подготовили, заложили какую-то часть фундамента: та же информатика много где есть.
Кто-то уже через пару месяцев на стажировке, и у них на прикладных задачах прогресс прет быстрее всех. А кто-то уже несколько лет в ленивом режиме проходит второй-третий курс, забывая предыдущее без практики.
Ну а большинство просто отваливаются уже на этом этапе. Интерес же к этой теме есть не у всех, а без интереса мотивация слабая. Некоторые потом возвращаются через год-два, иногда второй, третий раз, и часть из них даже рано или поздно все равно вливается.
Но не всем везет дойти до конца, тут ничего не поделать. Учеба - это тоже вполне себе серьезный труд.
Хорошо к этому подходят уже те, кто четко знает зачем они учатся, у кого есть твердая цель. Как правило это люди уже около 30-40, имеющие пару профессий за плечами, и четко осознающие зачем им айти, готовые ради своей цели на определенные жертвы, готовые тратить на это время, деньги, усилия, имеющие какую-никакую дисциплину и целеустремленность. Такие с самых первых дней на новой должности привлекают к себе внимание: они цельные, они ответственные, они усвоили свой объем знаний, на них можно положиться, они умеют общаться с людьми, через многое прошли, и боятся им в принципе уже нечего - все это прям неплохой такой трамплин в начале новой карьеры.