Резюме для программиста
Там надо по-итальянски
Не говориерунду. Набираешь виноград и идешь к кассе. Все как в лидле.
На пальцах общались.
На крайняк и так можно. В гостинице же справился ;)
Вобщем, резюме для программиста оказалось делом десятым. Опыт хотя бы 1 год в местных или просто известных фирмах, язык на уровне - и резюме нужно будет лишь формально. Поэтому дрочь на его вылизывание и узнавание каких-то якобы секретов его оформления, из-за которых вас тут же позовут на интервью и обязательно возьмут - туфта всё это. Разве что при поиске первого места работы это может как-то помочь. Но и то лучше "придумать" (не сильно привирая, правда) себе опыт работы, чем пытаться как-то особенно оформлять резюме - оно вернее сработает. Судя по опыту многих других - оно и у них вернее срабатывало.
Немцы называют форму ввода (input form) Maske? Постоянно это слышал, но не мог понять, что имеют ввиду. Похоже, это неофициальный термин, т.к. на форму ввода скорее встретишь Eingabeformular, чем Maske.
Офигеть! Королла у них не машина. Зажрались! Этот и предыдущий комменты.
Может кто-то объяснить, в чём суть, когда пишется один файл с кодом, а потом добавляется как ссылка (add existing file - add as link) к другим проектам? Чем это отличается от добавления проекта с этим файлом как зависимости?
А иногда и оба варианта сразу - добавляются одновременно и ссылка на файл с кодом, и библиотека с этим файлом как зависимость. Что за выкрутасы супер-архитектора?
Чем это отличается от
------
А подумать?
Все же хреново когда основ нету и изучать что-то лень.... 
Для этого и существуют всякие семизнаки на форумах - чтобы прийти и молча поправить всё быстро дать чёткий и по делу совет. ))
Вы лучше скажите, зачем в один и тот же проект одновременно добавлять и файл как ссылку, и ссылку на проект, в котором этот файл находится? Кто-то "мисскликнул"?
добавляются одновременно и ссылка на файл с кодом
оочень редко довольно удобная штука - расшаренный файл.
Используй файл где хочется, но при этом имеется только один оригинал.
Например, хотим иметь одни и те же коды ошибок в разных проектах. Городить целую либу для этого как то не хочется.
Т.е. расшаренный файл это заменитель маленькой либы?
А как его может использовать проект, который ссылку на такой файл имеет? Полный доступ к классам этого файла без подключения либы, его содержащей, как зависимости (project reference)?
Получается, что в принципе для работы на одной машине либы не нужны - можно всё такими расшаренными файлами расшарить? А либы лишь для дистрибуции создавать?
Смысла не вижу.
-----
Ааа... понял...
Смысл оказался слишком велик чтобы быть охваченнымодним не тренированным взглядом... 
А как его может использовать проект, который ссылку на такой файл имеет?
Точно также как и самый обычный текстовый файл. С точки зрения конечного потребителя - это самый обычный файл.
Я имею ввиду, вот есть у нас солюшен с проектами. И есть другой проект, который в солюшен не включен. Чтобы получить доступ к классам этого проекта, мы можешь либо подключить проект в солюшен, либо подключить либу, либо просто добавить ссылку на файл? И все классы из этого файла подгрузятся в солюшен, и можно будет перейти в этот файл по, например, команде "Go to Definition"? А при компиляции этот файл тоже будет скомпилирован? А проект этого файла будет скомпилирован? Ведь он не подключен.
Вот я и спрашиваю, насколько подключение файла как ссылки делает его полноценным участником открытого солюшена с проектами. И если такое подключение неполноценное, то зачем добавлять?
вангую, что просто добавив ссылку на файл, ты подключаешь только DLLку.
Таким образом компилироваться там больше нечему.
точно также как и посмотреть исходник.
Если что, под добавлением файла как ссылки я имею ввиду файл с исходным кодом (например .cs), не уже скомпиленную ДЛЛку. Этой ДЛЛки может просто не быть - исходник не скомпилен, а лишь подключен по ссылке. Если же при подключении по ссылке там под капотом делается куча операций, типа компиляции и подключения ДЛЛек, то это бред какой-то - проще уже весь проект с исходником или саму ДЛЛку подключить - нафига нужна новая сущность "добавить файл как ссылку"?
А закомпилить один лишь файл, без всех остальных файлов проекта, не всегда можно - может, у него зависимости от других файлов (классво) проекта? Тогда надо по цепочке подключить и всё остальное. Тогда проще весь проект подключить.
Короче, вся эта линковка - это какой-то бред. По крайней мере по отношению к файлам кода, которые должны компилиться. Уже существует механизм расшаривания файлов кода через подключение проектов и ДЛЛек, нахрена городить третий механизм и потом трахаться с добавлением залинкованных файлов в систему контроля версий и прочие. Может, для некомпилируемых файлов, типа ресурсов каких, это лучше подходит. Но и ресурсы тоже через подключение проектов и ДЛЛек шарятся.
Вот тут чел распинается, но нам важно, что в конце ("Why Would We Want to Link Files?") он приводит пример, когда это якобы полезно - иметь общий код среди проектов, которые нельзя подключить друг к другу. Тогда давайте мол шарить файлы через линковку. А если в пошаренных файлах юзаются пространства имён и классы, которые недоступны в типе проекта, который ты линкуешь? А вы мол не юзайте такие. Тогда почему бы не юзать .NET Standard, который как раз предназначен, чтобы иметь код, который общий для разных типов фреймворков, и шарить этот код между типами фреймворков, не подключаемыми друг к другу непосредственно (например .NET Framework и .NET)? - А куй его знает. Чел придумал костыль с линковкой и рад.
Короче, как я и думал, это очередной костыль для дерьма, которое нагородили в Майкрософт со своим зоопарком фреймворков, которые между собой несовместимы. Когда они раздуплятся и перейдут на один стандарт, один тип фреймворков (например текущий .NET), то вся эта херня станет не нужна.
Вот у меня сейчас в проекте переход с .NET Framework на .NET. Там до меня пытались это сделать - создали проекты .NET Standard и залинковали туда кучу файлов из .NET Framework. Нахрена? Если файлы эти по коду совместимы с .NET Standard, то почему бы сразу не создать эту либу и подключить её к проектам .NET Framework? А там, оказывается, не все файлы совместимы. Поэтому придётся проект на .NET Framework дробить - часть выносить в .NET Standard, а часть оставлять в .NET Framework. Он не хотел этого делать, и часть файлов залинковал, а часть переписал, чтобы были совместимы с NET Standard. В результате имеем мешанину из проектов, залинкованных файлов и прочей мути.
По-моему, лучше было всё таки раздробить на проекты. Потому что управление проектами в Студии и системе контроля версий как-то работает - для этого есть инфраструктура, а управление залинкованными файлами работает через задницу и вообще вносит кучу путаницы.
А вот и коммент оттуда про инфраструктуру (точнее её отсутствие) поддержки залинкованных файлов:
"All fine and good until you move the folder. Then you have to readd all the files by hand. If there are a thousand files.. might as well use another ide."