Смотрел фильм с десяток раз, это один из самых любимых моих фильмов, который с удовольствием можно смотреть в любое время при любом настроении. Больше всего в фильме понравилась глубина и детализация виртуального мира, даже самому захотелось побывать в таком. Большое количество отсылок к культуре 80х-90х годов согревает олдскульную душу. Сам фильм очень легкий и смотрится "на одном дыхании".
Возможно вам стоит посмотреть в сторону каких то онлайн курсов на udemy/coursera/яндексе, там, как правило, встречается больше всего практики (пример: https://practicum.yandex.ru/algorithms/).
Я бы не рекомендовал читать данную статью кому бы то ни было, тем более начинающему программисту.
Во-первых, как уже писали, айти - это далеко не только программисты. Во-вторых, пугать начинающего фронтендера тем, что ему в будущем нужно будет изучить ассемблер, чтоб стать "хорошим начинающим специалистом" - абсурд.
Я занимаюсь профессиональной разработкой более 17 лет и ни разу не сталкивался даже отдаленно с Haskell/Lisp/Elixir. А вот чего действительно у многих нынешних программистов не хватает - так это знаний основных комбинаторных алгоритмов.
Есть такой философский закон о переходе количества в качество. Первоначально довольно просто недооценить силу этого закона, но на мой взгляд его следы повсюду, буквально везде, в том числе и в понятии разум.
Образование - как строительство дома, без хорошего твердого фундамента, дом обречен на постоянные ремонты, а в худшем случае - на снос и отстрой заново.
В силу того, что работаю программистом, вынужден постоянно заниматься саморазвитием: чтением килотонн тех.документации, прохождением различных курсов (udemy, coursera). Это как раз и есть - освоение частного, но без общего - осваивать все это было бы очень затруднительно, и каждый раз в этом убеждаюсь, читая отзывы "вчерашних таксистов", решивших стать программистами.
Деградация образования началась еще до внедрения ЕГЭ, а способствующие этому реформы в образовании берут свои корни еще с развала СССР.
И хоть сегодня классические ВУЗы еще включают твердую математическую базу, осваивать ее сегодняшним школьникам - невероятно сложно.
Волосы на голове встают от нынешних школьных учебников: логика не последовательна, размыта, акцента на важных моментах нет, много "воды", однотипные и не однозначные в трактовке задания. Все это в купе с некомпетентным преподавательским составом дают нынешнее поколение несостоявшихся выпускников, не освоивших даже базу. Печально смотреть.
Любое образование должно обучать по принципу - от общего к частному (от математики к программированию). И до тех пор, пока наше образование будет следовать этому принципу - наши специалисты будут занимать первые места на интеллектуальных соревнованиях и будут признаваться всем миром как лучшие.
Закончив обучение в уральском классическом вузе в далеком 2008, могу с уверенностью заявить - такого образования с лихвой хватит для любых нынешних IT профессий. Да, там было не много специализированных курсов, но зато было много математики и комбинаторики, а основам обучали как положено, а все остальное студент может и сам изучить/освоить исходя из предпочтительных интересов в конкретной области.
Я начал подрабатывать во время учебы уже на 3м курсе в рядовой конторе по созданию сайтов - взяли на работу без проблем, уже через пол года пришло ощущение, что перерос контору в профессиональном развитии.
Мне вот 38, из них 17 работаю программистом, отчетливо помню время своего первого "выгорания", когда не видел смысла в работе, после понимания, что на новом месте работы все так же как и на прошлом. После чего еще раз "выгорел" несколько лет спустя на другом месте работы, после того, как долго реализуемая фича в продакшене не сыскала популярности. Сейчас, конечно, программирование уже не зажигает былой блеск в глазах и жажду все автоматизировать, но радость от мелких побед никуда не ушла, а заодно пришло понимание, что выгорание мне уже не грозит.
Хотелось бы оценить ваше детище, но из статьи о самом продукте сказано буквально несколько фраз. Знавал я в свое время пару чат-игр, которые были и остаются для меня единственными из данного жанра, в которые я играл, и которые мне очень понравились: http://xpl.github.io/gop/ и http://xpl.github.io/gop2/. К сожалению, в наше время жанр таких игр не слишком популярен и это надо учитывать при реализации. Второе рождение чат-играм могли бы подарить боты мессенджеров, но пока такого не наблюдается.
разработчики время от времени переходят в отдел поддержки
Я такого бреда в жизни не видывал. Серьезно, за свою достаточно долгую карьеру работы программистом (более 17 лет) - нигде, ни разу такого не видел и ни от кого не слышал. Хотя, надо признать, в целом, идея, конечно, не лишена смысла, но, как говорится, в реальном мире не выдерживает критики.
Описанное в статье - больше подходит к описанию мелкой канторы, в которой пишут небольшие сайты full-stack программисты уровня junior-middle.
Опытные разработчики делают ошибок немногим меньше, чем начинающие, но они быстрее их исправляют. В этом им помогают насмотренность и автоматизированные тесты, которые постоянно проверяют код.
Даже близко не так. Опытные разработчики могут писать целые программы/микросервисы почти без ошибок, в то время как начинающие делают миллион ошибок, а потом еще после код-ревью миллион исправлений (читай ошибок).
В действительности же начинать следует с самого простого, «деревянного» ответа на проблему пользователя — с решения, которое можно осуществить в короткий срок. При этом неважно, насколько это решение хорошее или плохое. Дальше анализируются преимущества и недостатки выбранного подхода, к решению добавляется что-то, усложняющее его и одновременно делающее лучше. И так шаг за шагом.
Такой подход годится, когда ваша небольшая noname-кантора делает первые шаги в мире разработки ПО, или чтоб по быстрее получить деньги и забыть о продукте, но такого подхода вам не простит ни одна серьезная организация. При проектировании нового продукта в нормальных организациях учитываются многие факторы, которые определяют спектр технологий, который может быть использован, и чаще всего выбор идет между одинаковыми по методу работы, конкурирующими технологиями.
Аннотации - это форма метаданных. Они предоставляют информацию о программе, при том сами частью программы не являются.
Откуда такое определение пошло ? В любом случае, применительно к java - оно не верно. Аннотации в наше время используются все чаще, притом именно в ходе выполнения программы. Не зря для этого есть целый набор для работы с аннотациями.
В современном мире разработки чаще применяется подход agile, в котором роль ТЗ выполняет userstory, которая описывает виденье нового функционала далекими от разработки людьми, после этого userstory прорабатывается и делится на уже конкретные мини-подзадачи аналитиками, либо тим-лидами, либо мини-собраниями команды разработки (планирование-грумминг). Таким образом процесс подготовки ТЗ разделен на этапы, минимизирующие риски в реализации и сроках.
В разных компаниях все по разному - в более мелких, программистам не редко приходится выполнять кучу разных ролей: аналитик, программист, тестировщик, девопсер, тех.писатель. Не редко в мелких компаниях и стартапах как такового ТЗ и вовсе нет. В более крупных компаниях разделение труда встречается гораздо чаще, в таких компаниях программисты чаще всего занимаются разработкой приложений строго по ТЗ, и отступление от него не то что не приветствуется, а очень даже наказывается.
Эта концепция (LST) как и вся статья в целом больше похожа на желаемое виденье устройства владельцами стартап-проектов.
Особенно насмешило "цикл развития разработчика (от джуна к миддлу или от миддла к синьору) сократился до 1-3 лет". А потом мы видим сеньоров с опытом 2 года, которые иногда даже не знают, что такое git. Выдача желаемого за действительное. В действительности же от разработчиков требуется наличие все большего количества знаний. Например, если раньше (лет 10 назад) сеньору-разработчику было достаточно знаний реляционных СУБД с практическим опытом в 1-2 реализациях. То сегодня - это знания джуна, а сеньор уже должен иметь знания в 2-3 типах СУБД и практический опыт в нескольких реализациях каждого типа. А знания всяких распределенных кластерных систем (типа Hadoop), всякие middleware-системы и прочее и прочее...
Я за последние 5 лет работал в 3х разных крупных компаниях (2 из них топ банки), и даже в них не встречал широкого использования SAST.
Автор не упомянул еще много чего, но как вы можете наблюдать из заголовка и текста статьи - целью было не описание всего, что есть, а ознакомление с часто используемыми инструментами в Java-проектах.
Смотрел фильм с десяток раз, это один из самых любимых моих фильмов, который с удовольствием можно смотреть в любое время при любом настроении. Больше всего в фильме понравилась глубина и детализация виртуального мира, даже самому захотелось побывать в таком. Большое количество отсылок к культуре 80х-90х годов согревает олдскульную душу. Сам фильм очень легкий и смотрится "на одном дыхании".
Книгу не читал.
Возможно вам стоит посмотреть в сторону каких то онлайн курсов на udemy/coursera/яндексе, там, как правило, встречается больше всего практики (пример: https://practicum.yandex.ru/algorithms/).
Я бы не рекомендовал читать данную статью кому бы то ни было, тем более начинающему программисту.
Во-первых, как уже писали, айти - это далеко не только программисты. Во-вторых, пугать начинающего фронтендера тем, что ему в будущем нужно будет изучить ассемблер, чтоб стать "хорошим начинающим специалистом" - абсурд.
Я занимаюсь профессиональной разработкой более 17 лет и ни разу не сталкивался даже отдаленно с Haskell/Lisp/Elixir. А вот чего действительно у многих нынешних программистов не хватает - так это знаний основных комбинаторных алгоритмов.
Есть такой философский закон о переходе количества в качество. Первоначально довольно просто недооценить силу этого закона, но на мой взгляд его следы повсюду, буквально везде, в том числе и в понятии разум.
Продвинутые технологии — одновременно и спасение, и проклятье (с)
Образование - как строительство дома, без хорошего твердого фундамента, дом обречен на постоянные ремонты, а в худшем случае - на снос и отстрой заново.
В силу того, что работаю программистом, вынужден постоянно заниматься саморазвитием: чтением килотонн тех.документации, прохождением различных курсов (udemy, coursera). Это как раз и есть - освоение частного, но без общего - осваивать все это было бы очень затруднительно, и каждый раз в этом убеждаюсь, читая отзывы "вчерашних таксистов", решивших стать программистами.
Деградация образования началась еще до внедрения ЕГЭ, а способствующие этому реформы в образовании берут свои корни еще с развала СССР.
И хоть сегодня классические ВУЗы еще включают твердую математическую базу, осваивать ее сегодняшним школьникам - невероятно сложно.
Волосы на голове встают от нынешних школьных учебников: логика не последовательна, размыта, акцента на важных моментах нет, много "воды", однотипные и не однозначные в трактовке задания. Все это в купе с некомпетентным преподавательским составом дают нынешнее поколение несостоявшихся выпускников, не освоивших даже базу. Печально смотреть.
Любое образование должно обучать по принципу - от общего к частному (от математики к программированию). И до тех пор, пока наше образование будет следовать этому принципу - наши специалисты будут занимать первые места на интеллектуальных соревнованиях и будут признаваться всем миром как лучшие.
Закончив обучение в уральском классическом вузе в далеком 2008, могу с уверенностью заявить - такого образования с лихвой хватит для любых нынешних IT профессий. Да, там было не много специализированных курсов, но зато было много математики и комбинаторики, а основам обучали как положено, а все остальное студент может и сам изучить/освоить исходя из предпочтительных интересов в конкретной области.
Я начал подрабатывать во время учебы уже на 3м курсе в рядовой конторе по созданию сайтов - взяли на работу без проблем, уже через пол года пришло ощущение, что перерос контору в профессиональном развитии.
Считаю советское образование - лучшим в мире.
По-моему не бывает такого, что все нравится :) Поначалу - возможно
Интересно было бы узнать возраст автора.
Мне вот 38, из них 17 работаю программистом, отчетливо помню время своего первого "выгорания", когда не видел смысла в работе, после понимания, что на новом месте работы все так же как и на прошлом. После чего еще раз "выгорел" несколько лет спустя на другом месте работы, после того, как долго реализуемая фича в продакшене не сыскала популярности. Сейчас, конечно, программирование уже не зажигает былой блеск в глазах и жажду все автоматизировать, но радость от мелких побед никуда не ушла, а заодно пришло понимание, что выгорание мне уже не грозит.
Хотелось бы оценить ваше детище, но из статьи о самом продукте сказано буквально несколько фраз. Знавал я в свое время пару чат-игр, которые были и остаются для меня единственными из данного жанра, в которые я играл, и которые мне очень понравились: http://xpl.github.io/gop/ и http://xpl.github.io/gop2/. К сожалению, в наше время жанр таких игр не слишком популярен и это надо учитывать при реализации. Второе рождение чат-играм могли бы подарить боты мессенджеров, но пока такого не наблюдается.
Я такого бреда в жизни не видывал. Серьезно, за свою достаточно долгую карьеру работы программистом (более 17 лет) - нигде, ни разу такого не видел и ни от кого не слышал. Хотя, надо признать, в целом, идея, конечно, не лишена смысла, но, как говорится, в реальном мире не выдерживает критики.
Описанное в статье - больше подходит к описанию мелкой канторы, в которой пишут небольшие сайты full-stack программисты уровня junior-middle.
Даже близко не так. Опытные разработчики могут писать целые программы/микросервисы почти без ошибок, в то время как начинающие делают миллион ошибок, а потом еще после код-ревью миллион исправлений (читай ошибок).
Такой подход годится, когда ваша небольшая noname-кантора делает первые шаги в мире разработки ПО, или чтоб по быстрее получить деньги и забыть о продукте, но такого подхода вам не простит ни одна серьезная организация. При проектировании нового продукта в нормальных организациях учитываются многие факторы, которые определяют спектр технологий, который может быть использован, и чаще всего выбор идет между одинаковыми по методу работы, конкурирующими технологиями.
Откуда такое определение пошло ? В любом случае, применительно к java - оно не верно. Аннотации в наше время используются все чаще, притом именно в ходе выполнения программы. Не зря для этого есть целый набор для работы с аннотациями.
Путь к популярности лежит через реализацию интеграций. Например реализацию spring data commons :)
Чем больше компания, тем больше в ней бюрократии и тем меньше участие конечного программиста в ТЗ.
В современном мире разработки чаще применяется подход agile, в котором роль ТЗ выполняет userstory, которая описывает виденье нового функционала далекими от разработки людьми, после этого userstory прорабатывается и делится на уже конкретные мини-подзадачи аналитиками, либо тим-лидами, либо мини-собраниями команды разработки (планирование-грумминг). Таким образом процесс подготовки ТЗ разделен на этапы, минимизирующие риски в реализации и сроках.
Скорее всего автор описывает свою текущую боль)
В разных компаниях все по разному - в более мелких, программистам не редко приходится выполнять кучу разных ролей: аналитик, программист, тестировщик, девопсер, тех.писатель. Не редко в мелких компаниях и стартапах как такового ТЗ и вовсе нет. В более крупных компаниях разделение труда встречается гораздо чаще, в таких компаниях программисты чаще всего занимаются разработкой приложений строго по ТЗ, и отступление от него не то что не приветствуется, а очень даже наказывается.
Эта концепция (LST) как и вся статья в целом больше похожа на желаемое виденье устройства владельцами стартап-проектов.
Особенно насмешило "цикл развития разработчика (от джуна к миддлу или от миддла к синьору) сократился до 1-3 лет". А потом мы видим сеньоров с опытом 2 года, которые иногда даже не знают, что такое git. Выдача желаемого за действительное. В действительности же от разработчиков требуется наличие все большего количества знаний. Например, если раньше (лет 10 назад) сеньору-разработчику было достаточно знаний реляционных СУБД с практическим опытом в 1-2 реализациях. То сегодня - это знания джуна, а сеньор уже должен иметь знания в 2-3 типах СУБД и практический опыт в нескольких реализациях каждого типа. А знания всяких распределенных кластерных систем (типа Hadoop), всякие middleware-системы и прочее и прочее...
Я за последние 5 лет работал в 3х разных крупных компаниях (2 из них топ банки), и даже в них не встречал широкого использования SAST.
Автор не упомянул еще много чего, но как вы можете наблюдать из заголовка и текста статьи - целью было не описание всего, что есть, а ознакомление с часто используемыми инструментами в Java-проектах.
Я бы порекомендовал переименовать статью в "История утечки персональных данных через Github". Это сильно разные вещи.