Здравствуйте, Rupper, Вы писали:
R>Устал отвечать на вопросы. R>Предлагаю еще раз. R>Условия — работа в офисе, полный рабочий день. R>Будут командировки в питер. Будут выходы в субботу. Будут мероприятия
Куда вам посылать резюме?
Re[10]: Предлагаю работу еще раз.
От:
Аноним
Дата:
16.10.03 08:09
Оценка:
Здравствуйте, Аноним, Вы писали:
А>>Должен быть минимальный кругозор. если у человека есть "любимый язык" и он дальше него носа еще не высовывал — то пусть в своей песочнице и ковыряется. в носу
А>Покажи свой кругозор. Какими другими способами можно реализовать полиморфизм и где это применяется?
Здравствуйте, Аноним, Вы писали: А>Лучше вежливо сказать "нам нужен боец покруче", чем говорить, что 800 это для меня нормальная цена, после того, как в объявлении написано от 900. А>Снижать цену ниже объявленной, я такого не понимаю. А>В купе со штрафами и выходами по субботам — это просто дает кумулятивный эффект.
Видимо он хотел тебя взять, но не понял, что тебе лучше отказать, чем предложить на 100 баксов меньше. На твоем месте я возможно поступил бы так же как и ты — отказался бы от такого предложения. С другой стороны это его право предлагать за работу столько, сколько он считает нужным. Если он попытался при этом воспользоваться ситуацией и таким образом зажать 100 баксов — ату его. Выше он уверяет, что и в мыслях у него такого не было. Видать на те 100 баксов в месяц, что он хотел сэкономить, он планировал воспользоваться услугами другого программиста, который бы выполнил ту работу, которую по его мнению не мог выполнять ты ввиду наличия пробелов в твоих знаниях.
Здравствуйте, DarkGray, Вы писали:
R>>И кстати у этих гавриков теперь есть опыт как делать ненадо. У других нет. Не очень я верю что это была подпольная группа мазохистов, которые будут повторять это снова и снова.
DG>Есть категория программистов, которым больше нравится ходить нестандартными тропами, и которые больше думают о том, как применить "вчера вычитанный" хитрый трюк, а не о конечном результате. С такими программистами надо ухо держать востро и иногда осаживать.
Это обычно проявляется между вторым и третьим годом опыта и достаточно быстро и безболезненно проходит. Можешь таких людей архитектурой заинтересовать и станет легче жить. Хотя будет некий "овердизайн", но это не страшно в отличие от страшных хаков, просто времени маленько тратит. Через пару лет само все пройдет будет хороший программер.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, Аноним, Вы писали:
А>>Здравствуйте, Аноним, Вы писали:
А>>>Интересно... А что, наличие виртуальных методов автоматически предполагает виртуальную таблицу? В приципе, можно представить человека, знакомого с виртуальностью (полиморфизмом) и не разу не слышавшего о виртуальной таблице. В его любимом языке это по другому реализуется.
А>>Должен быть минимальный кругозор. если у человека есть "любимый язык" и он дальше него носа еще не высовывал — то пусть в своей песочнице и ковыряется. в носу
А>Покажи свой кругозор. Какими другими способами можно реализовать полиморфизм и где это применяется?
В Delphi есть модификатор dynamic вместо virtual, чтобы виртуальные таблицы размер программы не увеличивали. Сильно походит когда у класса много виртуальных функций но они редко перегружаются.
Кроме того VMT есть несколько видов. В основном это касается реализации смещения указателя this при множественном наследовании, у страуструпа почитай в Дизайн и Эволюция C++
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте, Awaken, Вы писали:
R>>Интересно а что за редкий вид такой который "в совершенстве" знает C# ? R>>Это что он знает ? Что он умеет ? Пишет 1000 строк кода в день, которые компилируется но ничего
A>у нас в команде работают люди которые перешли на C# после VB6.0. естественно они не знают A>что такое виртуальная база, но опыт разработки крупных корпоративных систем имеют (на VB+Oracle)
A>не все программисты по дефолту являются специалистами в C++.
Я маленько насторожено отношусь к людям которые применяли языки только с автоматической сборкой мусора.
Для переучивания(т.е. для того чтобы человек стал параноиком) нужно как минимум пол года. Это не значит что я не готов брать их на работу, но если в дополнение к VB есть хотя бы 3-4 месяца классического C, даже не C++ то это гораздо лучше.
Аналогично с людьми которые никогда не писали на языках без компонент. Т.е. и VB и Delphi влияют не лучшим образом на ООП дизайн если ничего кроме них никогда не было.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
А>>А зачем такие навороты (по технологиям и профессионализму программистов), когда фирма (ultracomp), грубо говоря, продажей железа занимается?
R>А фирма McDonalds вообще пирожки делает... R>И ничего. свой штат программеров есть.
Могу кстати подтвердить что требования самые средние, никакие это не навороты. Описанный уровень близок к требованиям которые я предъявляю к программерам, просто хороший средний уровень.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
M>Вот тут небольшое замечание. Если вы собираетесь писать под Oracle, то навыки MSSQL разработчика могут даже навредить. M>Так что MSSQL'иста все равно придется переучивать и во что это выльется зависит от степени закоренелости оного, может оказаться проще научить вообще с нуля..
Щазззз. Все равно человек который примерно понимат как запросы выполняются гораздо более полезен чем тот кто RDBMS вообще не видел. Помню я людей которые писали хранимые процедуры у которых временная сложность была O(n*n*n*n). Потом радостно докладывали что у них на табличке в 10 записей все работает...
В теории RDBMS ничего кардинально не изменилось годов так с 70-80. Так что опыт в любой базе пригодится. А Transisolation под конкретный сервер выучить это фигня все.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте, Anatolix, Вы писали:
A>Щазззз. Все равно человек который примерно понимат как запросы выполняются гораздо более полезен чем тот кто RDBMS вообще не видел.
Ага, ты это расскажи тому, кто за MSSQL'истом под Oracle переписывал, или наоборот...
Каждый случай индивидуален.
A>В теории RDBMS ничего кардинально не изменилось годов так с 70-80. Так что опыт в любой базе пригодится. А Transisolation под конкретный сервер выучить это фигня все.
То, что в теории ничего не изменилось — полностью согласен, но есть некоторые нюансы. Во первых практикующие программисты не очень склонны увлекаться теорией. Во вторых людам свойственно думать, что если похоже, то уж как-нибудь разбирусь, SELECT-то — он везде одинаково пишется и ленятся заглянуть лишний раз в документацию, что может закончится очень печально. И, наконец, в третьих, теория RDBMS конечно практически не поменялась, но даже в этой теории Multiversioning и Blocking Concurrency Control местами довольно серьезно отличаются, не говоря уже о том, что конкретные реализации всегда имеют свои далеко не очевидные особенности.
Вообщем суть в том, что навыки наработанные для одного сервера не всегда годятся для другого, и в некоторых случаях проще научить заново чем периучивать, новичек по крайней мере не будет питать иллюзий, что он что-то знает.
Угу.. Вот только бывает, что соискатель не может написать SELECT, например, с внешним соединением или группировкой — то есть у него этот SELECT не пишется одинаково для всех СУБД
Здравствуйте, Igor Trofimov, Вы писали:
M>>SELECT-то — он везде одинаково пишется
iT>Угу.. Вот только бывает, что соискатель не может написать SELECT, например, с внешним соединением или группировкой — то есть у него этот SELECT не пишется одинаково для всех СУБД
Будешь прикалываться но в стандарте SQL 92 внешних JOIN-ов нету поэтому
они например в MSSQL и ORACLE пишутся по разному
LEFT JOIN ON
и
a.a(+)=b.b
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте, Anatolix, Вы писали:
A>Здравствуйте, Igor Trofimov, Вы писали:
M>>>SELECT-то — он везде одинаково пишется
iT>>Угу.. Вот только бывает, что соискатель не может написать SELECT, например, с внешним соединением или группировкой — то есть у него этот SELECT не пишется одинаково для всех СУБД
A>Будешь прикалываться но в стандарте SQL 92 внешних JOIN-ов нету поэтому A>они например в MSSQL и ORACLE пишутся по разному A>LEFT JOIN ON A>и A>a.a(+)=b.b
Не буду прикалываться.
LEFT JOIN это по умолчанию INNER
а вот LEFT(RIGHT) OUTER JOIN в Oracle давно есть в 9i точно есть про восьмерку не помню — там я еще с плюсиками писал.
Здравствуйте, Merle, Вы писали:
A>>Щазззз. Все равно человек который примерно понимат как запросы выполняются гораздо более полезен чем тот кто RDBMS вообще не видел. M>Ага, ты это расскажи тому, кто за MSSQL'истом под Oracle переписывал, или наоборот... M>Каждый случай индивидуален.
Это так же как переписывает с GNU C на MSVC и наоборот. Гоблины лепят. Хорошие программисты задумываются о переносимости(не пишут переносимо все т.к. иногда это невозможно или того не стоит, но хотя бы могут сказать что вот эти 15% запросов нужно будет переписать а остальные нет)
A>>В теории RDBMS ничего кардинально не изменилось годов так с 70-80. Так что опыт в любой базе пригодится. А Transisolation под конкретный сервер выучить это фигня все. M>То, что в теории ничего не изменилось — полностью согласен, но есть некоторые нюансы. Во первых практикующие программисты не очень склонны увлекаться теорией.
Писать правильные быстрые запросы это практика и она тоже не изменилась.
>Во вторых людам свойственно думать, что если похоже, то уж как-нибудь разбирусь, SELECT-то — он везде одинаково пишется и ленятся заглянуть лишний раз в документацию, что может закончится очень печально.
А у люжей без опыта есть тендеция лепить как получится и это почти всегда оканчивается печально.
>И, наконец, в третьих, теория RDBMS конечно практически не поменялась, но даже в этой теории Multiversioning и Blocking Concurrency Control местами довольно серьезно отличаются, не говоря уже о том, что конкретные реализации всегда имеют свои далеко не очевидные особенности.
Здесь проблемы будут при OLTP системах с длинными транзакциями или которые удаляют большое количество записей по ходу работы. И то и другое редкость(иногда встречаются системы которые делают это но неоправданно, т.е. можно сделать без этого и проще). Никто и не сомневается что в 10% случаях без профи не обойтись. Но тогда нужно например и искать выделенного спеца по Oracle.
M>Вообщем суть в том, что навыки наработанные для одного сервера не всегда годятся для другого, и в некоторых случаях проще научить заново чем периучивать, новичек по крайней мере не будет питать иллюзий, что он что-то знает.
Как правило новички считают что они знают все, либо их просто ничего не волнует. Классический пример — возмешь новичка первое что сделает это начнет SQL формировать с помощью сложения строк вместо параметров. Наступит потом что в параметре будет кавычка. Человек с опытом в любом сервер на это уже наступал наверняка
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте, Anatolix, Вы писали:
A>Здравствуйте, Merle, Вы писали:
A>>>Щазззз. Все равно человек который примерно понимат как запросы выполняются гораздо более полезен чем тот кто RDBMS вообще не видел. M>>Ага, ты это расскажи тому, кто за MSSQL'истом под Oracle переписывал, или наоборот... M>>Каждый случай индивидуален.
A>Это так же как переписывает с GNU C на MSVC и наоборот. Гоблины лепят. Хорошие программисты задумываются о переносимости(не пишут переносимо все т.к. иногда это невозможно или того не стоит, но хотя бы могут сказать что вот эти 15% запросов нужно будет переписать а остальные нет)
A>>>В теории RDBMS ничего кардинально не изменилось годов так с 70-80. Так что опыт в любой базе пригодится. А Transisolation под конкретный сервер выучить это фигня все. M>>То, что в теории ничего не изменилось — полностью согласен, но есть некоторые нюансы. Во первых практикующие программисты не очень склонны увлекаться теорией.
A>Писать правильные быстрые запросы это практика и она тоже не изменилась.
>>Во вторых людам свойственно думать, что если похоже, то уж как-нибудь разбирусь, SELECT-то — он везде одинаково пишется и ленятся заглянуть лишний раз в документацию, что может закончится очень печально. A>А у люжей без опыта есть тендеция лепить как получится и это почти всегда оканчивается печально.
>>И, наконец, в третьих, теория RDBMS конечно практически не поменялась, но даже в этой теории Multiversioning и Blocking Concurrency Control местами довольно серьезно отличаются, не говоря уже о том, что конкретные реализации всегда имеют свои далеко не очевидные особенности.
A>Здесь проблемы будут при OLTP системах с длинными транзакциями или которые удаляют большое количество записей по ходу работы. И то и другое редкость(иногда встречаются системы которые делают это но неоправданно, т.е. можно сделать без этого и проще). Никто и не сомневается что в 10% случаях без профи не обойтись. Но тогда нужно например и искать выделенного спеца по Oracle.
M>>Вообщем суть в том, что навыки наработанные для одного сервера не всегда годятся для другого, и в некоторых случаях проще научить заново чем периучивать, новичек по крайней мере не будет питать иллюзий, что он что-то знает.
A>Как правило новички считают что они знают все, либо их просто ничего не волнует. Классический пример — возмешь новичка первое что сделает это начнет SQL формировать с помощью сложения строк вместо параметров. Наступит потом что в параметре будет кавычка. Человек с опытом в любом сервер на это уже наступал наверняка
Тут про параметризацию надо упомянуть что Oracle кэширует запрос.
Т.е. неважно, может даже в параметрах и не будет кавычек, но параметризация позволяет значительно повысить производительность.
Здравствуйте, Anatolix, Вы писали:
A>Писать правильные быстрые запросы это практика и она тоже не изменилась.
А вот практика как раз отличается.... Есть куча тонкостей, которые не плохо бы знать.
Работа с временными таблицами, особенности оптимизатора, особенности PLSQL'я, особенности блокировок...
Встрять можно на ровном месте.
A>Здесь проблемы будут при OLTP системах с длинными транзакциями или которые удаляют большое количество записей по ходу работы.
И не только.
A>Но тогда нужно например и искать выделенного спеца по Oracle.
Об том и речь. Автору топика нужно быстро, а периучивать — та еще задачка.
A>Будешь прикалываться но в стандарте SQL 92 внешних JOIN-ов нету поэтому A>они например в MSSQL и ORACLE пишутся по разному A>LEFT JOIN ON A>и A>a.a(+)=b.b
Ой, да пусть он хоть как написал бы
Я же не говорю "напиши с LEFT JOIN". Я даю две крохотные таблички и табличку — желаемый результат.
Иногда и внутренее (ни через JOIN, ни через WHERE ) соединение сделать не могут.
Здравствуйте, Anatolix, Вы писали:
A>Будешь прикалываться но в стандарте SQL 92 внешних JOIN-ов нету поэтому
Я буду, можна?
Раз пошла такая пьянка, вот мой предпоследний огурец:
[sql92]
Specify a table derived from a Cartesian product, inner or outer
join, or union join.
Format
<joined table> ::=
<cross join>
| <qualified join>
| <left paren> <joined table> <right paren>
Здравствуйте, Merle, Вы писали:
A>>В теории RDBMS ничего кардинально не изменилось годов так с 70-80. Так что опыт в любой базе пригодится. А Transisolation под конкретный сервер выучить это фигня все. M>То, что в теории ничего не изменилось — полностью согласен, но есть некоторые нюансы.
Нюансы и знания MSSQL вредны это все таки не одно и то же .
M>И, наконец, в третьих, теория RDBMS конечно практически не поменялась, но даже в этой теории Multiversioning и Blocking Concurrency Control местами довольно серьезно отличаются, не говоря уже о том, что конкретные реализации всегда имеют свои далеко не очевидные особенности.
Особенности версионников и блокировочников важны при оптимизации. Для программиста, основаня задача которого писать дотнетный код, а не хитрые запросы, это некритично. Для команды в 4 человека достаточно 1 спеца по ораклу. Я так понимаю что проверялся прежде всего базовый набор знаний — что такое select, ХП, триггер и т.п.
M>Вообщем суть в том, что навыки наработанные для одного сервера не всегда годятся для другого,
Тут не навыки по моему ищутся, а знания.
M> и в некоторых случаях проще научить заново чем периучивать,
Ты уверен что человека, плохо разбирающегося в RDBMS будет легче научить ораклу, нежели того кто работал с MSSQL?
M>новичек по крайней мере не будет питать иллюзий, что он что-то знает.
Это не от новичковости зависит, а от личностных качеств.
Выше он уверяет, что и в мыслях у него такого не было. Видать на те 100 баксов в месяц, что он хотел сэкономить, он планировал воспользоваться услугами другого программиста, который бы выполнил ту работу, которую по его мнению не мог выполнять ты ввиду наличия пробелов в твоих знаниях. 
Мы уже победили, просто это еще не так заметно...
