бесполезно у студента спрашивать гулбокое понимание Java или .NET.

 

Вот я непонимаю, что значит "глубокое понимание Java или .NET"... Не могли бы вы прояснить?

 

Если я скажем знаю, как в Hotspot устроен сборщик мусора или там регаллок, это глубокое понимание или нет?

 

У меня есть конечно идея, что под глубоким пониманием подразумеваются вопросы а-ля "сколько параметров принимает метод org.hibernate.loader.criteria.CriteriaJoinWalker.getJoinType и какой эксепшн он выбрасывает если третим параметром передать null" (я конечно утрирую, но судя по всему такие вопросы иногда задают на собеседованиях). Так вот если меня когда-нибудь спросят на собеседовании такой вопрос, я могу случайно дать интервьюирующему в чан стулом...

Блин. Что делать с экзепшн - обработкой ошибок. Что такое слои приложения и как распределять по ним функциональность. База данных- left inner join что делает? UI. Технологии, NET, xml, html, wpf, winforms, javascript (java, ...). Локализация. ООП - зачем с чем едят? ОРМ - зачем? Ну и тд и тп. Какие параметры принимает метод важно для времени, чем меньше вы знаете, тем больше времени = денег заказчика потрачено. Как работает сборщик мусора можете забить, лучше запомните что такое и как устроен Dictionary. Как работает сборщик - 0 ценности по сути.

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

В наше кризисное время идет сокращение аутсорса в России. Я очень сомневаюсь что тот же интел повышает зарплаты в зависимости от курса $, а скажем такие конторы как моторолла просто тупо сворачивают свою деятельность, возможно как и Интел в недалеком будущем.

А на пятки наступают индийцы с 8-12$ в час и прочие пакистанцы. Вот это объективная реальность, а не 3000$ после окончания вуза.

Блин.

 

Это вы мне отвечаете? Ну так я не вас спрашивал. С вами-то мне в принципе всё понятно: вы гнёте свою (не скажу что уж очень интересную мне) линию.

 

Хотя вопрос про Dictionary он как-то даже выбивается из общего ряда некоторой фундаментальностью.

 

Как работает сборщик - 0 ценности по сути.

 

Ну-ну. :hahaha:

Как работает сборщик - 0 ценности по сути.

Ну-ну. :hahaha:

Плюс пицот. :)

Как работает сборщик - 0 ценности по сути.

 

Ммм... А ничего, что не зная этого гораздо легче создавать memory leak-и?

AmbassadorKosh, ro_man, Dassie

Лучше приведите пример, когда вам помог сборщик мусора убрать мемори лики и тп. Я абсолютно честно признаю что был неправ.

Включу в список маст хэв, и тп.

AmbassadorKosh, ro_man, Dassie

Лучше приведите пример, когда вам помог сборщик мусора убрать мемори лики и тп. Я абсолютно честно признаю что был неправ.

Включу в список маст хэв, и тп.

Сборщик мусора и есть один большой толстый мемори лик. Отказываешься от языка со сборщиком и избавляешься от него :)

AmbassadorKosh, ro_man, Dassie

Лучше приведите пример, когда вам помог сборщик мусора убрать мемори лики и тп. Я абсолютно честно признаю что был неправ.

Включу в список маст хэв, и тп.

 

Например, тут - http://blogs.sun.com/fkieviet/entry/classl...he_dreaded_java довольно конкретно описано чего не стоит делать, почему и как это связано со сборщиком.

 

Кстати я не говорил, что сборщик помогает их убирать. Я утверждаю, что непонимание механизма его работы в некоторых случаях "помогает" их создавать.

Лучше приведите пример [...] Включу в список маст хэв, и тп.

 

Вы неправильно подходите к вопросу: смотрите исключительно со своей прикладной колокольни...

Вы никогда не думали, что сборщик мусора в том же CLR не с неба упал, а был кем-то написан (вот сюрприз-то!). JIT компилятор CLR тоже кем-то написан. И вообще каждый компонент CLR кем-то написан. Причем не пришельцами из космоса, а вполне себе человекоподобными существами.

 

Как думаете, для них самое ценное знание ("маст хэв" в вашей интерпретации) это left inner join и html?

 

 

Вы неправильно подходите к вопросу: смотрите исключительно со своей прикладной колокольни...

Вы никогда не думали, что сборщик мусора в том же CLR не с неба упал, а был кем-то написан (вот сюрприз-то!). JIT компилятор CLR тоже кем-то написан. И вообще каждый компонент CLR кем-то написан. Причем не пришельцами из космоса, а вполне себе человекоподобными существами.

 

Как думаете, для них самое ценное знание ("маст хэв" в вашей интерпретации) это left inner join и html?

 

Речь, вроде как, шла о глубоком знании java.

 

Тот же сборщик мусора не на java написан.

 

Думаю, "маст хэв" тоже относился к java разработчикам. Хотя наличие в списке HTML и иже с ним, наводит на мысль, что он относится скорее к требованиям конкретной организации.

Речь, вроде как, шла о глубоком знании java.

 

Речь шла о том, что я не понимаю, что такое глубокое знание Java или .NET.

Я понимаю, что такое "знать на зубок API", но это неглубокое знание доступное любой макаке, коими сейчас рынок достаточно насыщен и состязатся с коими я не вижу ни смысла, ни возможности... Предпочту наизусть учить стихи, нежели API.

 

Тот же сборщик мусора не на java написан.

 

Можно и Java написать =)

 

наводит на мысль, что он относится скорее к требованиям конкретной организации.

 

Скорее человек просто перечислил всё, что он сам знает...

Речь шла о том, что я не понимаю, что такое глубокое знание Java или .NET.

Я понимаю, что такое "знать на зубок API", но это неглубокое знание доступное любой макаке, коими сейчас рынок достаточно насыщен и состязатся с коими я не вижу ни смысла, ни возможности...

 

В моем понимании, глубокое знание инструмента ( к коим отнесу и java & .NET) это понимание его возможностей и ограничений.

 

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

 

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

 

Как-то так.

Предпочту наизусть учить стихи, нежели API.

:)

Спрос на кодирование привёл к смещению интерпретации социумом названия профессии в направлении от Creativity к Productivity.

Вечное прекрасно, но за него, как правило, платят мало.

Глубокое знание популярной технологии приносит доход, но недолго и надоедает.

Браво. :kos:

Кстати, вот еще подумалось - глубокое знание гитары еще не сделает вас музыкантом....

Блин. Что делать с экзепшн - обработкой ошибок. Что такое слои приложения и как распределять по ним функциональность. База данных- left inner join что делает? UI. Технологии, NET, xml, html, wpf, winforms, javascript (java, ...). Локализация. ООП - зачем с чем едят? ОРМ - зачем? Ну и тд и тп. Какие параметры принимает метод важно для времени, чем меньше вы знаете, тем больше времени = денег заказчика потрачено. Как работает сборщик мусора можете забить, лучше запомните что такое и как устроен Dictionary. Как работает сборщик - 0 ценности по сути.

Деньги платят за работу а не за абстракнтые знания.

 

[...]

 

А на пятки наступают индийцы с 8-12$ в час и прочие пакистанцы. Вот это объективная реальность, а не 3000$ после окончания вуза.

Есть два измерения в найме на работу:

- Какую работу найти проще с приемлемой оплатой

- За что платят больше всего (одному человеку, а не суммарно всем владеющим квалификацией)

 

Так вот перечисленные вами знания позволят найти работу быстро, но это будет далеко не топ. И вам всегда на пятки будут наступать "индийцы с $8-12 в час и прочие пакистанцы".

Знание устройства сборщика мусора и прочих потрохов управляемых сред востребовано реже, но в определённых проектах может быть оплачено несравнимо выше. И я знаю несколько подобных проектов ведущихся в окрестностях, в т.ч. один в Intel Новосибирск. Как я уже писал, некоторое время назад одними из самых выскооплачиваемых программистов были те, кто умеет программировать и настраивать SAP R3, вакансий таких не много, но и соискателей единицы.

 

http://www.cyberforum.ru/job/thread21830.html

Кстати, вот еще подумалось - глубокое знание гитары еще не сделает вас музыкантом....

 

Могу согласиться на все 100, если Вы имеете ввиду знание о том, как правильно ремонтировать гитару, настраивать её некоторые параметры. Я до сих пор не хочу знать как в моей гитаре можно немного увеличить расстояние струн от грифа (это должна быть элементарная операция, намного проще, чем замена крана на кухне, но гитара достаточно дорогая, чтобы позволить себе экспериментировать).

 

А вообще мне с каждым годом всё больше нравится принцип как минимум одной американской софтверной компании: программистам там строго велено не заниматься установкой антивирусов и прочими непрофильными делами — для этого там пишется заявка и приходит специальный специалист, который всё налаживает и в случае необходимости даже восстанавливает до рабочего состояния.

 

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