Посоветуйте, что дальше изучать
чем больше будешь знать - тем лучше энивей =) на разных работах разные требоования и разные подходы к интервью. кому то действительно интересен узкий круг кглубоких знаний, но как правило все таки стараются пробивать на широту кругозора, смекалку и общую адекватность.
чтобы собеседования проходить - это легко, делаешь пару-тройку заходов по левым вакансиям (места с неплохими требованиями но которые не жалко слить и на основе тех вопросов что там задают делаешь выводы. рекомендуется делать в начале каждой итерации поиска новой работы =) ну плюс в инете можно прям погуглить чтото вроде "вопросы на собеседовании c#", посетить форумы тематические типа rsdn.ru - хотя там уже довольно изощренные вещи как правило.
что изучать.
основы ооп (паттерны, антипаттерны, рефакторинг популярные фреймворки (орм, мвц, иок, етц научиться работать с транзакциями и понимать зачем они нужны, вообще бест практисес по тем типам проектов, которыми ты занимаешься, познакомиться с юнит тестами, про экстрим программинг почитать и вокруг, языков выучить побольше (от маленьких типа регэкспа\икспаса до больших типа лиспа про устройство гарбадж коллектора заботать, по бд какую нить основу почитать типа дейта, активно выботать все типсы, трики, шорткаты и прочие возможности своей любимой иде, цвс если не дай бог не заботано, по криптографии хотя бы основы, по сетям и сетевым протоколам чем больше тем лучше, поставить что то из *nix и учиться в нем работать.
взять за правило, что прежде чем прогать какой то относительно самостоятельный кусок кода, стоит слазить в гугл. задача минимум - найти в гугле уже готовый кусок кода. задача максимум, найти реализацию более оптимальную, нежели смог бы написать ты сам.
потом можно начинать полировать знания - заботать профилировщики, почитать про железный уровень, попробовать себя в асме, читать код правильных опенсурс проектов (ядра ос, етц ботать как можно больше всяких странных алгоритмов, читать классиков.
если из каких то буковок что то непонятно - спрашивай, все расписывать ломает =)
чтобы собеседования проходить - это легко, делаешь пару-тройку заходов по левым вакансиям (места с неплохими требованиями но которые не жалко слить и на основе тех вопросов что там задают делаешь выводы. рекомендуется делать в начале каждой итерации поиска новой работы =) ну плюс в инете можно прям погуглить чтото вроде "вопросы на собеседовании c#", посетить форумы тематические типа rsdn.ru - хотя там уже довольно изощренные вещи как правило.
что изучать.
основы ооп (паттерны, антипаттерны, рефакторинг популярные фреймворки (орм, мвц, иок, етц научиться работать с транзакциями и понимать зачем они нужны, вообще бест практисес по тем типам проектов, которыми ты занимаешься, познакомиться с юнит тестами, про экстрим программинг почитать и вокруг, языков выучить побольше (от маленьких типа регэкспа\икспаса до больших типа лиспа про устройство гарбадж коллектора заботать, по бд какую нить основу почитать типа дейта, активно выботать все типсы, трики, шорткаты и прочие возможности своей любимой иде, цвс если не дай бог не заботано, по криптографии хотя бы основы, по сетям и сетевым протоколам чем больше тем лучше, поставить что то из *nix и учиться в нем работать.
взять за правило, что прежде чем прогать какой то относительно самостоятельный кусок кода, стоит слазить в гугл. задача минимум - найти в гугле уже готовый кусок кода. задача максимум, найти реализацию более оптимальную, нежели смог бы написать ты сам.
потом можно начинать полировать знания - заботать профилировщики, почитать про железный уровень, попробовать себя в асме, читать код правильных опенсурс проектов (ядра ос, етц ботать как можно больше всяких странных алгоритмов, читать классиков.
если из каких то буковок что то непонятно - спрашивай, все расписывать ломает =)
Стандартные алгоритмы знаюэто включается в слово стандартные? =)
Я студент младшего курса, есть опыт работы с SQL, C++, C# и немного с UML и XML, работаю немного больше года. Стандартные алгоритмы знаю, но сейчас повторяю их.Сами по себе знания малоценны. Пытайся делать какие-то программы для себя. Т.е. вот прям думаешь, что бы можно было из деятельности, которую ты делаешь за компом, автоматизировать и пишешь программу.
Вопрос в том, что бы еще освоить, чтобы успешно проходить собеседования. Как я понял по опыту работы, совсем не надо офигенно знать даже непосредственно тот язык, на котором прогаешь, часто надо знать небольшой раздел, поэтому и прошу совета.
Посоветуйте пожалуйста, дополнительные технологии, которые могут сгодиться к моим знаниям. Желательно со ссылками на литературу.
Это даст умение применять знания.
что изучать.основы ооп (паттерны, антипаттерны, рефакторинг популярные фреймворки (орм, мвц, иок, етц научиться работать с транзакциями и понимать зачем они нужны, вообще бест практисес по тем типам проектов, которыми ты занимаешься, познакомиться с юнит тестами, про экстрим программинг почитать и вокруг, языков выучить побольше (от маленьких типа регэкспа\икспаса до больших типа лиспа про устройство гарбадж коллектора заботать, по бд какую нить основу почитать типа дейта, активно выботать все типсы, трики, шорткаты и прочие возможности своей любимой иде, цвс если не дай бог не заботано, по криптографии хотя бы основы, по сетям и сетевым протоколам чем больше тем лучше, поставить что то из *nix и учиться в нем работать.взять за правило, что прежде чем прогать какой то относительно самостоятельный кусок кода, стоит слазить в гугл. задача минимум - найти в гугле уже готовый кусок кода. задача максимум, найти реализацию более оптимальную, нежели смог бы написать ты сам.потом можно начинать полировать знания - заботать профилировщики, почитать про железный уровень, попробовать себя в асме, читать код правильных опенсурс проектов (ядра ос, етц ботать как можно больше всяких странных алгоритмов, читать классиков.я бы твой пост в обратном порядке прокручивал.
т.е. начать с классиков/правильных ос проектов, закончить транзакциями/популярными фреймворками/"основами ооп".
Поизучай ассемблер. Можешь небольшое ядро многозадачной операционки написать в качестве практики.
я бы твой пост в обратном порядке прокручивал.Спорный вопрос =) Понятно, что как минимум из-за дыр в абстракциях, нужно знать всю вертикаль, но с чего начинать - с практики или с теории - большой вопрос.
т.е. начать с классиков/правильных ос проектов, закончить транзакциями/популярными фреймворками/"основами ооп".
Плюс стоило бы уточнить с какого фака чел. Если с вмик - то в общем то достаточно выбатывать профильные экзамены до состояния сдачи на отлично, и про классику можно временно забыть.
ну не знаю. если под практикой понимать чтение исходников, я не вижу особенной вероятности говнокода.
гораздо легче начать говнокодить, неправильно (слишком буквально, к примеру) интерпретировав книги.
к примеру, на практике многие понимают ГоФ слишком буквально.
копировать подход из прочитанных исходников — безопаснее, я считаю. =)
там содержится уже переваренный кем-то умным ГоФ.
гораздо легче начать говнокодить, неправильно (слишком буквально, к примеру) интерпретировав книги.
к примеру, на практике многие понимают ГоФ слишком буквально.
копировать подход из прочитанных исходников — безопаснее, я считаю. =)
там содержится уже переваренный кем-то умным ГоФ.
как тут не процитировать строфы маяковского, часть которых была в известной подписи контры. =)
похоже я выступлю против двух предыдущих ораторов =)
проще сказать что не следует делать
не суйся ни в какие архитектурные-оптимизационные-ассемблерные тонкости, этим часто грешат новички.
в них достаточно знать совсем базовые основы, остальное никогда не пригодится.
не стоит без надобности изучать какие-то огромные высокоуровневые системы/фреймворки/теории/абстракции если текущая задача изначально с ними не связана. их слишком много и большинство из них устареет раньше чем с ними столкнёшься.
ИМХО очень полезно хорошо знать какой-нить стандартный универсальный скриптовый язык, чтоб вот-прямо-вот-сейчас реализовать любую фигню.
проще сказать что не следует делать
не суйся ни в какие архитектурные-оптимизационные-ассемблерные тонкости, этим часто грешат новички.
в них достаточно знать совсем базовые основы, остальное никогда не пригодится.
не стоит без надобности изучать какие-то огромные высокоуровневые системы/фреймворки/теории/абстракции если текущая задача изначально с ними не связана. их слишком много и большинство из них устареет раньше чем с ними столкнёшься.
ИМХО очень полезно хорошо знать какой-нить стандартный универсальный скриптовый язык, чтоб вот-прямо-вот-сейчас реализовать любую фигню.
Вопрос ко всем: а можете для разных языков/технологий привести достойные проекты, исходники которых следует читать для просвещения? Например, для С часто называют ядро линукса. Для С++, я помню, кто-то хвалил WebKit. Еще примеры?
nginx! 
для C еще Judy можно почитать (из интерналс 6-го перла) и питон тут фж советовал.
also: из того, с чем плотно имел дело: memcached — ужасен, firefox — ужасен. =)
для C еще Judy можно почитать (из интерналс 6-го перла) и питон тут фж советовал.
also: из того, с чем плотно имел дело: memcached — ужасен, firefox — ужасен. =)
в ядре там тоже не всё красиво. kernel, net и mm ничо так, а как в drivers глянешь — бррр =)
ИМХО очень полезно хорошо знать какой-нить стандартный универсальный скриптовый язык, чтоб вот-прямо-вот-сейчас реализовать любую фигню.имхо если пользоваться каким-нибудь юниксом, рано или поздно такая потребность появляется сама.
под винду скрипты пишут только такие героические люди, как , по-моему. =)
ну правильно - драйверы это самая большая часть кода, там есть код без мантейнеров, которой трогают, только когда удаляют устаревшие конструкции с помощью грепа -)
а kernel и mm много раз переписывали
а kernel и mm много раз переписывали
ну не знаю. если под практикой понимать чтение исходников, я не вижу особенной вероятности говнокода.Читать исходники - это все-таки не для нубов занятие. Чтобы читать код, надо неплохо разбираться во всем, что в коде используется. Язык, сами паттерны, апи. Иначе это будет довольно неэффективный процесс. Выделять из кода неизвестные паттерны - довольно нетривиальная задача, тем более для начинающего программиста.
гораздо легче начать говнокодить, неправильно (слишком буквально, к примеру) интерпретировав книги.Тут уже нужен индивидуальный подход. Не уверен, что выботка кучи кода перед чтением паттернов как-то спасет.
к примеру, на практике многие понимаю ГоФ слишком буквально.
На самом деле, на мой взгляд большие опасности в другом. Например, по моим наблюдениям, 90% людей начинающих кодить на языках с ексепшенами, не умеют их правильно применять. В джаве с ее checked exception'ами дело осложняется тем, что сплошь и рядом возникают комбинации типа try {...} catch(Exception e) {/*do nothing, annoying exceptions =F*/}.
С NPE проблема тоже остро стоит. И, что самое смешное, в популярных классиках мало где объясняется, как правильно со всем этим жить.
Как раз сейчас мне в наследство достался проект, в котором сплошь и рядом в веб-приложении, крутящемся на OAS, с завидным упорством повторяется след говнокод
DBTransaction tr = createTransaction;
try {
//call some pl/sql procs
} catch(SQLException e) {
System.out.println(e.getMessage;
}
tr.commit;
После такого кода мне уже все равно, сколько и каких там человек прочитал классиков, и чего он там из теории алгоритмов знает. За этим человеком надо перепроверять ВЕСЬ код. Иначе, как пиздецом, это не назовешь.
копировать подход из прочитанных исходников — безопаснее, я считаю. =)Ну как сказать. Если читать чужой код без прочтения оригинала, то есть риск испорченного телефона.
там содержится уже переваренный кем-то умным ГоФ.
Все таки имхо стоит прочитать сначала ГоФ, а потом уже учиться применять полученные знания, читая чей-то код.
Вообще, понятие оптимального порядка изучения - сугубо индивидуально имхо. Надо смотреть, что человек уже знает, и оттуда строить план, что надо узнать.
если под практикой понимать чтение исходников, я не вижу особенной вероятности говнокода.я вот тут подумал немного и понял, что более конструктивно не просто читать исходники или писать какие-то проекты с нуля, а писать плагины к существующим программам: Miranda, jEdit, Eclipse, Photoshop, Firefox, Gimp и любым другим, которыми пользуешься и которые это поддерживают. Это позволит не только познакомиться с дизайном хорошего/популярного проекта, но и сделать какую-то законченную и полезную другим хрень.
Взять тот же jEdit (текстовый редактор с возможностью писать к нему плагины, чем воспользовались жуткие сотни разработчиков): написать плагин легко, в процессе написания полностью понимаешь, как круто они там все придумали, и даже где именно у них закончилась фантазия и пошли-таки хаки (хотя бы немного хаков есть, пожалуй, в любом проекте). При этом, написав полезный плагин, о нем узнают сотни-тысячи-триллионы людей, в отличие от случая, когда пишешь еще-один-notepad руками.
в том-то и фишка! если читать код, в котором нет таких говноконструкций, то когда тебе захочется написать такую говноконструкцию,DBTransaction tr = createTransaction;
try {
//call some pl/sql procs
} catch(SQLException e) {
System.out.println(e.getMessage;
}
tr.commit;
ты поймешь, что не знаешь, как это сделать! зато знаешь, как сделать правильную конструкцию.
а об архитектуре и паттернах на первых этапах подумает архитектор.
я на примере наших пхп-программистов знаю, как вредно на первых этапах думать об архитектуре.
зато, читая код, можно научиться круто и правильно кодить. это очень важно на самом деле. очень!
я вот тут подумал немного и понял, что более конструктивно не просто читать исходники или писать какие-то проекты с нуля, а писать плагины к существующим программам:именно! именно!
писать плагины и в непонятных местах читать/понимать интерналс — это офигеть, как полезно и хорошо. =)
даже лучше, чем со своих программ начинать, пожалуй, да.
Спасибо! А что-нибудь на С#, Java, Lisp, Haskell, Brainfuck? 
HaskellС этим туго
Чем гурее автор, тем тяжелее там что-нибудь понимать... Например, HAppS 0.8 был еще читаемым, 0.9 я уже не осилил
Хотя стандартная библиотека, местами, вполне себе ничего...
А для jEdit-а плагины разве не на java?
А вообще много где (в том же Лисе, Флэш) плагины на JavaScript - имхо вполне универсальный язык и достаточно широко применимый
А вообще много где (в том же Лисе, Флэш) плагины на JavaScript - имхо вполне универсальный язык и достаточно широко применимый
Паттерны, Антипаттерны, матчасть.
я так понимаю две первые части аннигилируют и остаётся только суть =)
JavaLucene
ее когда отрефакторили года два назад - код стал просто загляденье
хз, правили ли его с тех пор в связи с выходом джавы5
Вот тоже было бы интересно узнать, какие есть полезные для изучения опен-сорс проекты на C#, а их что-то никто пока не привел.
beagle написан на C#
полезный или нет --- не знаю
полезный или нет --- не знаю
Спасибо тем, кто написал по делу. А другой язык стоит заботать? Java или еще что-то. а то было мнение, что популярность С++ падает что-то.
Кстати, я с ФФ, если что, прогами занялся относительно недавно. Опыт работы около года, если не писал.
И еще: если есть пиздатые ссылки по теме, то кидайте.
Кстати, я с ФФ, если что, прогами занялся относительно недавно. Опыт работы около года, если не писал.
И еще: если есть пиздатые ссылки по теме, то кидайте.
Стоит
Какой-нибудь из функциональных
Haskell, OCaml (или другой *ML CL (common lisp)
Даже если не будешь на нем работать, такое знание очень помогает
Какой-нибудь из функциональных
Haskell, OCaml (или другой *ML CL (common lisp)
Даже если не будешь на нем работать, такое знание очень помогает
Можешь ещё F# попробовать.
Это будет первый функциональный язык, поддерживаемый Microsoft'ом.
Для платформы .NET
Это будет первый функциональный язык, поддерживаемый Microsoft'ом.
Для платформы .NET
Оставить комментарий
Retor
Я студент младшего курса, есть опыт работы с SQL, C++, C# и немного с UML и XML, работаю немного больше года. Стандартные алгоритмы знаю, но сейчас повторяю их.Вопрос в том, что бы еще освоить, чтобы успешно проходить собеседования. Как я понял по опыту работы, совсем не надо офигенно знать даже непосредственно тот язык, на котором прогаешь, часто надо знать небольшой раздел, поэтому и прошу совета.
Посоветуйте пожалуйста, дополнительные технологии, которые могут сгодиться к моим знаниям. Желательно со ссылками на литературу.