А почему нет? в нашем мире все практически термины. По хорошему нужно переводить всегда, когда есть понятный аналог в родном языке. А оставлять оригинал, если перевод не слишком очевиден или сложен.
Это странно звучит на фоне того, что в плюс питону ставят мол он скриптовый, очень удобно. И вот вы предлагаете пойти по пути компилируемых языков, тем самым намекая, что плюса у питона и не было.
Так с таким успехом, если удобство синтаксиса определяется не синтаксисом, а ИДЕ в которой ты пишешь, то и у баша замечательный синтаксис и у с подобных, если в правильной ИДЕ кодить.
Это какой такой классический синтаксис у питона? по моему там синтаксис отсутствует как понятие вообще. Эти дурацкие пробелы, с которыми постоянно куча проблем. Но главный подвох в том, что вроде бы все построено на пробелах, но ифы ты двоеточиями закрывай, да и циклы тоже закрывай и много чего еще и встает вопрос, а зачем тогда было делать все на пробелах, если по итогу я выборочно буду завершение строк проставлять?
Я так понял рекрутеры совсем перестали работать и теперь задача работника не только хорошо работать, но и вместо рекрутера уметь самого себя правильно оценить и описать? Какой план дальше для работников, отказаться от зп если хочешь попасть под алгоритмы?
Все нужные нужные технические статьи были написаны давно в книгах и журналах. А потом, начались форумы, блоги прорадители хабра и стало невозможно искать нормальные технические статьи. Спасите книги. Если вдруг вы не поняли, то хабр пошел по логическому пути, как и все кто был до него. Пока ты молодой начинающий проект, ты притягиваешь людей, потом ты развиваешься и начинаешь превращаться в помойку.
То-то я смотрю в винде как проблема, так сразу заново ее переустанавливают, а линукс чинят и дальше пользуются. Видимо это все от вашего " linux чаще молча падает."
В те годы, выбор операционных систем для смартфонов был крайне невелик: по сути, производителям были доступны только две системы.
Так, ну вот не нада, ощущение, что часть людей пребывала в параллельной вселенной. У моторолы еще с далеких начала нулевых были телефоны на чистом линуксе со всеми вытекающими плюшками из мира opensource. Да там были нюансы, но собщество все эти нюансы решило и вы тогда имели полноценный линукс, которым вы сегодня пользуетесь повсеместно.
Добро пожаловать в действительность. По факту, вы сами верно ответили на свои вопросы. Я процитирую: "На рынок тысячами валят junior разработчики. Есть годные, есть мотивированные, есть халявщики, есть блатные, есть трудолюбивые, ленивые, белые, красные — любые. Да, выбирать сложно и найти хороших ещё тяжелее. Но ведь почти никто не пытается."
Обычно тут 2 причины. Слухи о хороших зп, и модность направления. И второе в приоритете. Например не сформировавшийся специалист, который пока не понимает какие есть направления и чем конкретно там занимаются, вот он и бродит с места на места в поисках. И вот он ищет куда пойти дальше, а тут с каждого утюга вещают про какиенить курсы, про модное направление и тд и он решает туда пойти. Ему по сути без разницы куда, но раз подвернулось на глаза что это модно, значит нужно туда. Ни в коем случаи не говорю про тех, что давно сформировался и четко понимает свое направление.
Так рекрутерам никто и не публикует куски кода на тех анализ. Но если рекрутер совсем не понимает то, чем будет заниматься тех спец, а просто подбирает по красивым словам и приятному слогу, тогда к чему эта лишняя прослойка в его лице? В итоге это привело к тому, что все гонятся за тем, как вы написали , чтобы попасть в выборку, а технический навык ушел на второй план. Я понимаю почему тех лиды жалуются, что нету кадров достойных. Они есть, просто они не попали в эту красивую выборку, т.к. не копирайтеры и не поэты чтобы сочинять резюме.
Не буду все комментировать, прокомментирую один момент который меня всегда убивал. Почему тех спец, должен как-то там править резюме, расставлять акценты и структурировать информацию, чтобы ее было легко читать? Тех спец должен писать, что он умеет. А уже уметь это разобраться и правильно структурировать как раз таки задача HR, ибо в чем задача HR, если они просто читают готовое резюме специально подготовленное для них, чтобы они там что-то не упустили? Это равноценно как мне будут давать готовый код, который я буду только компилить и гордо говорить, что этот мой код ))
Двоякое ощущение от статьи, даже не знаю как коментить. С одной стороны, если разбираться все по предложениями, то можно много к чему придраться. С другой стороны, если отталкиваться от идеи, что большинство HR уже давно не ищут спеца или человека с потенциалом, а просто подбирает красивые резюме - то в целом статья пригодится многим, даже несмотря на грязные приемы.
Просто в винде половина прог с уже вкомпилеными библиотеками. Собирайте на линухе статично программы и будет совместимость, никто не запрещает так делать. Суть в том, что это не нужно, это неправильно так делать.
А вы наивно полагаете, что с этих всех дисков ставились все пакеты? Вставьте диск 3 вполне себе происходил ради одного пакета на пару мб, а весь оставшийся диск мог быть запит ПО которое использует пол процента в мире. Я уже молчу про наличие в репе пакетов разных версий и под разные архитектуры и даже исходники пакетов.. Я даже не буду говорить про хотябы отдаленно попытаться прикинуть на сколько дисков поместится весь набор винды во всех ее редакциях, архитектурах, включая бесконечное множество повторяющегося ПО и и сходников. Так что да, в линуксе маленькие программы, так и есть.
Стоит заметить, что фрэймворков фрэймворков рознь. Но на мой скромный взгляд, большая часть из них г.. . В погоне за возможность покрыть все хотелки под все проекты, да и еще как можно быстрее, фрэймворков разрослись до невероятных размеров, пожирают кучу ресурсов и чтобы разобраться в этих на скорую руку сделанных хитросплетениях необходимо чуть ли не к авторам обращаться. Посему со временем с такими фрэймворками приходят к мысли, а давайте мы все перепишем заново на своем коде. И эти фраемворки движутся по пути - давайте их похоронем все. Ведь основная задача это побыстрее накидать проект и срубить бабло с заказчика, а как оно там будет работать это уже второстепенно. Но есть и хорошие фрэймворки, где вместо всех хотелок, пытались избавить разработчика от написания повторяющего кода - как итог, относительно небольшие и достаточно быстрые фрэймворки которые при некоторой сноровке от разработчика покрою почти все задачи. Но кому это нужно, пару лишних строк кода накидать. Да и ради чего, чтобы это все работало быстрее? Да это уже не забота разработка, он свалил с проекте через несколько лет.
3 полка вещь, но посидеть на второй полке тоже хорошая идея. Что если предложеный вариант, от окна сдвинуть еще чуть больше и при этом сделать ее до конца до прохода.
А про дверьку переговорную тетя на трубе дело говорит, идея хорошая но что если замок сломается да и в целом надеяться что никто не влезит плохая идея. Как вариант стекло с дырками делать, а открываться просто с двух сторон дверька у каждого. Хз на сколько это практично, но зато точно физически не пролезеш, ну и полялякать можно.
А почему нет? в нашем мире все практически термины. По хорошему нужно переводить всегда, когда есть понятный аналог в родном языке. А оставлять оригинал, если перевод не слишком очевиден или сложен.
Как тут не вспомнить классика )
Когда уже телефоны вернуться к нормальному линуксу с нормальными фреймворками?
Это странно звучит на фоне того, что в плюс питону ставят мол он скриптовый, очень удобно. И вот вы предлагаете пойти по пути компилируемых языков, тем самым намекая, что плюса у питона и не было.
Так с таким успехом, если удобство синтаксиса определяется не синтаксисом, а ИДЕ в которой ты пишешь, то и у баша замечательный синтаксис и у с подобных, если в правильной ИДЕ кодить.
Это какой такой классический синтаксис у питона? по моему там синтаксис отсутствует как понятие вообще. Эти дурацкие пробелы, с которыми постоянно куча проблем. Но главный подвох в том, что вроде бы все построено на пробелах, но ифы ты двоеточиями закрывай, да и циклы тоже закрывай и много чего еще и встает вопрос, а зачем тогда было делать все на пробелах, если по итогу я выборочно буду завершение строк проставлять?
Я так понял рекрутеры совсем перестали работать и теперь задача работника не только хорошо работать, но и вместо рекрутера уметь самого себя правильно оценить и описать?
Какой план дальше для работников, отказаться от зп если хочешь попасть под алгоритмы?
Все нужные нужные технические статьи были написаны давно в книгах и журналах. А потом, начались форумы, блоги прорадители хабра и стало невозможно искать нормальные технические статьи.
Спасите книги.
Если вдруг вы не поняли, то хабр пошел по логическому пути, как и все кто был до него. Пока ты молодой начинающий проект, ты притягиваешь людей, потом ты развиваешься и начинаешь превращаться в помойку.
То-то я смотрю в винде как проблема, так сразу заново ее переустанавливают, а линукс чинят и дальше пользуются. Видимо это все от вашего " linux чаще молча падает."
Так, ну вот не нада, ощущение, что часть людей пребывала в параллельной вселенной.
У моторолы еще с далеких начала нулевых были телефоны на чистом линуксе со всеми вытекающими плюшками из мира opensource. Да там были нюансы, но собщество все эти нюансы решило и вы тогда имели полноценный линукс, которым вы сегодня пользуетесь повсеместно.
Добро пожаловать в действительность. По факту, вы сами верно ответили на свои вопросы.
Я процитирую:
"На рынок тысячами валят junior разработчики. Есть годные, есть мотивированные, есть халявщики, есть блатные, есть трудолюбивые, ленивые, белые, красные — любые. Да, выбирать сложно и найти хороших ещё тяжелее. Но ведь почти никто не пытается."
Обычно тут 2 причины. Слухи о хороших зп, и модность направления. И второе в приоритете.
Например не сформировавшийся специалист, который пока не понимает какие есть направления и чем конкретно там занимаются, вот он и бродит с места на места в поисках. И вот он ищет куда пойти дальше, а тут с каждого утюга вещают про какиенить курсы, про модное направление и тд и он решает туда пойти. Ему по сути без разницы куда, но раз подвернулось на глаза что это модно, значит нужно туда.
Ни в коем случаи не говорю про тех, что давно сформировался и четко понимает свое направление.
Так рекрутерам никто и не публикует куски кода на тех анализ. Но если рекрутер совсем не понимает то, чем будет заниматься тех спец, а просто подбирает по красивым словам и приятному слогу, тогда к чему эта лишняя прослойка в его лице?
В итоге это привело к тому, что все гонятся за тем, как вы написали , чтобы попасть в выборку, а технический навык ушел на второй план.
Я понимаю почему тех лиды жалуются, что нету кадров достойных. Они есть, просто они не попали в эту красивую выборку, т.к. не копирайтеры и не поэты чтобы сочинять резюме.
Прошли те времена, уже давно крупные игроки нагибают клиентов по полной и ничего никто не сделает. В лучшем случаи осознают, что их нагнули.
Так тогда в принципе можно не покупать винду, а ставить бесплатные ОСи. А если лишние деньги появятся, то лучше пожертвовать в opensource.
Не буду все комментировать, прокомментирую один момент который меня всегда убивал.
Почему тех спец, должен как-то там править резюме, расставлять акценты и структурировать информацию, чтобы ее было легко читать?
Тех спец должен писать, что он умеет. А уже уметь это разобраться и правильно структурировать как раз таки задача HR, ибо в чем задача HR, если они просто читают готовое резюме специально подготовленное для них, чтобы они там что-то не упустили?
Это равноценно как мне будут давать готовый код, который я буду только компилить и гордо говорить, что этот мой код ))
Двоякое ощущение от статьи, даже не знаю как коментить.
С одной стороны, если разбираться все по предложениями, то можно много к чему придраться.
С другой стороны, если отталкиваться от идеи, что большинство HR уже давно не ищут спеца или человека с потенциалом, а просто подбирает красивые резюме - то в целом статья пригодится многим, даже несмотря на грязные приемы.
Просто в винде половина прог с уже вкомпилеными библиотеками.
Собирайте на линухе статично программы и будет совместимость, никто не запрещает так делать. Суть в том, что это не нужно, это неправильно так делать.
А вы наивно полагаете, что с этих всех дисков ставились все пакеты? Вставьте диск 3 вполне себе происходил ради одного пакета на пару мб, а весь оставшийся диск мог быть запит ПО которое использует пол процента в мире. Я уже молчу про наличие в репе пакетов разных версий и под разные архитектуры и даже исходники пакетов.. Я даже не буду говорить про хотябы отдаленно попытаться прикинуть на сколько дисков поместится весь набор винды во всех ее редакциях, архитектурах, включая бесконечное множество повторяющегося ПО и и сходников.
Так что да, в линуксе маленькие программы, так и есть.
Стоит заметить, что фрэймворков фрэймворков рознь. Но на мой скромный взгляд, большая часть из них г.. . В погоне за возможность покрыть все хотелки под все проекты, да и еще как можно быстрее, фрэймворков разрослись до невероятных размеров, пожирают кучу ресурсов и чтобы разобраться в этих на скорую руку сделанных хитросплетениях необходимо чуть ли не к авторам обращаться. Посему со временем с такими фрэймворками приходят к мысли, а давайте мы все перепишем заново на своем коде. И эти фраемворки движутся по пути - давайте их похоронем все. Ведь основная задача это побыстрее накидать проект и срубить бабло с заказчика, а как оно там будет работать это уже второстепенно.
Но есть и хорошие фрэймворки, где вместо всех хотелок, пытались избавить разработчика от написания повторяющего кода - как итог, относительно небольшие и достаточно быстрые фрэймворки которые при некоторой сноровке от разработчика покрою почти все задачи. Но кому это нужно, пару лишних строк кода накидать. Да и ради чего, чтобы это все работало быстрее? Да это уже не забота разработка, он свалил с проекте через несколько лет.
3 полка вещь, но посидеть на второй полке тоже хорошая идея. Что если предложеный вариант, от окна сдвинуть еще чуть больше и при этом сделать ее до конца до прохода.
А про дверьку переговорную тетя на трубе дело говорит, идея хорошая но что если замок сломается да и в целом надеяться что никто не влезит плохая идея. Как вариант стекло с дырками делать, а открываться просто с двух сторон дверька у каждого. Хз на сколько это практично, но зато точно физически не пролезеш, ну и полялякать можно.