Здравствуйте, EM, Вы писали:

EM>Такой экзамен есть — вступительное interview. Без него трудно "практиковать" И оно по-определению серьезней, чем сдача какого-нить кандидатского диссера — экзаменующий материально заинтересован в результате.

Нет, это не так по нескольким причинам.

Во-первых, умение ездить собеседнику по ушам — это такой же скил как и умение писать код. Наибольшего успеха добивается тот, кто умеет и то и другое. Так вот для интервьюирующего понять где правда, а где бла-бла-бла очень трудно. Причём чем на более судьбоносную позицию набирается человек, тем труднее это различить. Теперь берём в качестве примера большие консалтинги, такие как MS и IBM. Для них главное — срубить бабло и чем более профессионально их архитекторы умеют ездить по ушам кастомерам, тем для них лучше. Всё бы ничего, но потом эти же архитекторы начинают принимать технические решения, который порой принимают самые причудливые формы. Но прикрываясь брендом и вышеупомянутым скилом можно продавить абсолютно всё. Самое перчальное, что этих людей если и интервьюируют, то в основном менеджеры, а не технари, да и MS с IBM делают всё возможное чтобы этот процесс из контракта вовсе исключить. Вы разве не верите Microsoft? Сомневаетесь, что вы получите настоящий солюшин от IBM? А зачем вы тогда сюда пришли?

Второй момент. Известный факт, что достаточно только одному индусу попасть на минимальски руководящую должность, как тут же вся структура под ним становится индусской. Если он идёт вверх по служебной лестнице, то за ним образуется характерный шлейф. Как ты думаешь, у тебя много шансов пройти в такую контору интервью?

Третье. Необходимость качественного софта — это фикция, просто декларация. Качественный софт никому не нужен. Если ты группой в пять квалифицированных бойцов сделаешь за год качественную систему, то через год все эти пять бойцов будут сидеть и от безделья бацаться в офисе в Дум. Ещё через пол года их всех уволят вместе с их начальником. Если же на их место взять 20 посредственностей, то такой проект не закончится никогда, будут выходить патчи, заплатки, заявленные ранее фичи будут откладываться на потом и так до бесконечности. Но всем будет хорошо, 20 человек при деле и начальника никто не уволит.

В принципе, я не против всего этого, ради бога. Если MS с IBM по полной натягивют кастомеров, значит кастомеры получают от этого удовольствие. Если банки нанимают в IT департмент только индусов — это их дело. Начальники любят посредственностей — файн. Я хочу лишь одного — чтобы все эти бла-бла-бла-архитекторы и тяп-ляп-девелоперы не заблуждались считая себя экстроординаными личностями... и стояли по стойке смирно, когда с ними разговаривают старшие и более опытные товариши И слушали при этом внимательно, потому что у старших и более опытных товаришей не так много времени объяснять всё по 15 раз. Задолбали уже совсем

Вот такая правда жизни Ладно, это я так... шутю, устал малость, предыдущий абзац можно игнорировать

Здравствуйте, IT, Вы писали:

IT>Второй момент. Известный факт, что достаточно только одному индусу попасть на минимальски руководящую должность, как тут же вся структура под ним становится индусской. Если он идёт вверх по служебной лестнице, то за ним образуется характерный шлейф. Как ты думаешь, у тебя много шансов пройти в такую контору интервью?

И все таки я был прав. Был у тебя начальником индус!

Здравствуйте, Mika Soukhov, Вы писали:

IT>>Второй момент. Известный факт, что достаточно только одному индусу попасть на минимальски руководящую должность, как тут же вся структура под ним становится индусской. Если он идёт вверх по служебной лестнице, то за ним образуется характерный шлейф. Как ты думаешь, у тебя много шансов пройти в такую контору интервью?

MS>И все таки я был прав. Был у тебя начальником индус!

Почитай внимательнее, там же ясно написано, что если начальник индус, то шансов к нему попасть практически нет

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, EM, Вы писали:

EM>>Такой экзамен есть — вступительное interview. Без него трудно "практиковать" И оно по-определению серьезней, чем сдача какого-нить кандидатского диссера — экзаменующий материально заинтересован в результате.

IT>Нет, это не так по нескольким причинам.

<... поскипаное с интересом прочитано ...>

IT>Третье. Необходимость качественного софта — это фикция, просто декларация. Качественный софт никому не нужен. Если ты группой в пять квалифицированных бойцов сделаешь за год качественную систему, то через год все эти пять бойцов будут сидеть и от безделья бацаться в офисе в Дум. Ещё через пол года их всех уволят вместе с их начальником. Если же на их место взять 20 посредственностей, то такой проект не закончится никогда, будут выходить патчи, заплатки, заявленные ранее фичи будут откладываться на потом и так до бесконечности. Но всем будет хорошо, 20 человек при деле и начальника никто не уволит.

Вот здесь, имхо, перегиб. Если пятеро бойцов создадут удачный продукт, который найдет широкое применение, то они будут загружены работой по сопровождению (не только в виде bug-fixing-а) и развитию этого продукта настолько, что все равно придется нанимать еще 20 посредственностей, "чтобы снаряды подносили". И есть шанс, что первоначальная команда распадется как раз из-за обилия монотонной и однообразной работы по добавлению очередной небольшой фичи.

Хотя, может сказанное тобой в большей степени относится к заказному софту, а сказанное мной -- к коробочному. Все же в этих двух направлениях цели, ориентиры и приоритеты различаются.

<... поскипаное с интересом прочитано ...>

Здравствуйте, EM, Вы писали:

EM>Такой экзамен есть — вступительное interview. Без него трудно "практиковать" И оно по-определению серьезней, чем сдача какого-нить кандидатского диссера — экзаменующий материально заинтересован в результате.

Просто для объективной оценки сказанного тобой: у тебя самого есть защищенный кандидатский дисcер?

Здравствуйте, IT, Вы писали:

IT>>>Второй момент. Известный факт, что достаточно только одному индусу попасть на минимальски руководящую должность, как тут же вся структура под ним становится индусской. Если он идёт вверх по служебной лестнице, то за ним образуется характерный шлейф. Как ты думаешь, у тебя много шансов пройти в такую контору интервью?

MS>>И все таки я был прав. Был у тебя начальником индус!

IT>Почитай внимательнее, там же ясно написано, что если начальник индус, то шансов к нему попасть практически нет

Это при условии того, что индус пришел в начальство раньше. А если позднее, когда ты уже работал Игорь, расскажи, как ты умеешь держать такую ненависть к азиатским народам и при этом работать в стране, которая не терпит рассковых предрассудков?

Если серьезно, то насчет десяти не уверен, но могу вспомнить несколько действительно важнейших:
1 — Действительно разумная логика.
Проблема заключается в написании такой программы. Ведь программа впринципе не может быть умнее своего создателя , а зачастую она оказывается намного хуже. К тому же такая программа будет требовать выполнения ОГРОМНОГО количества операций по перекачке данных с одного угла в другой. И нужно так же очччень много памяти. От программы как таковой потребуется правильная организация данных, чтобы не хранить видеофрагменты целиком, а представлять их в ментальном виде, также нужно будет создать блоки, которые преобразовывали бы физический сигнал (звук, видео, осязание и т.д.) в объектный поток, так например человек помнит разговор не по звукам, а по словам, а уже потом, вспоминая, мозг идет по кучам ссылок, забирая по песчинке, чтобы в итоге получилось воспоминаение, имитирующее реальность. Мозгу проще создавать ссылки, каждая клетка имеет тысячи контактов с другими клетками (а то и больше) и в итоге может легко направить поток данных в другую клетку, добавив от себя еще частичку. Каждая клетка — небольшой примитивный процессор, а в ПК процессор один и в этом самая главная сложность. И последняя из основных трудностей реализации этой задачи — образование. Невозможно за пару часов вложить в разумное создание то, что другое не менее разумное создание изучало в течение десятилетий. Однако, стоит обучит всему одного "робота", как можно будет эти знания скопировать другим. Кстати, программа должна будет делать ошибки так, чтобы они никогда не вели к сбою и исправлялись моментально.
2 — сжатие данных
Тут нет предела совершенству. Раньше думали, что zip — это все, предел, пик (а может и не думали), а потом rar появился, который мог еще больше сжать zip файл. Уверен, появится метод еще лучше, который сможет любой rar сжать в несколько раз. Проблема в недостатке производительности и в нахождении и реализации хорошего алгоритма.
3 — Защита данных.
Как сказал Ньютон, на каждое действие есть свое противодействие. Так же и везде. И в защите — на всякую защиту найдется свой ключ. Раньше методы были примитивными — замена алфавита другими символами, перемена мест символов в алфавите, метод Вижинера (хотя это не такой уж примитивный метод, но и его сломали), добавление числа к числовому аналогу текста, гаммирование, и проч. и проч. и проч. Тем не менее теоретически можно взломать любую систему защиты, вопрос только во времени, которого всегда мало. Создать такой метод шифрования, который даже теоретически невозможно будет взломать — вот третья задача.
4 — Исправление багов и повышение производительности.
Чем больше программа, тем больше в ней ошибок, трат, недочетов и прочих недостатков, причем в геометрической прогрессии. Самым меньшим из всех зол является трата ресурсов, поэтому зачастую возникновение ошибок сводят к минимуму именно за счет "прожорливости" программы, создания огромных блоков отлавливания ошибок и т.д. Если бы windows был бы совершенством, он мог бы поместиться на дискету и выполняться в тысячи раз быстрее. Для каждой цели есть свои средства, так для повышения производительности используется ассемблер, но на нем оччччень долго и трудоемко написать большой проект. Для них используется например Си, но Си забирает очень много производительности. Для исправления багов используется время, но оно, как я уже говорил, всегда ограничено.

Пожалуй, это пока все, что могу вспомнить. Остальное мелочно и незначительно, на фоне этих проблем
Сюда я редко захожу, поэтому ответы лучше на мыло: killen_co@e-mail.ru

IT,

IT>Третье. Необходимость качественного софта — это фикция, просто декларация. Качественный софт никому не нужен. Если ты группой в пять квалифицированных бойцов сделаешь за год качественную систему, то через год все эти пять бойцов будут сидеть и от безделья бацаться в офисе в Дум. Ещё через пол года их всех уволят вместе с их начальником. Если же на их место взять 20 посредственностей, то такой проект не закончится никогда, будут выходить патчи, заплатки, заявленные ранее фичи будут откладываться на потом и так до бесконечности. Но всем будет хорошо, 20 человек при деле и начальника никто не уволит.

Возможно это от плохого настроения, но вывод неправильный. Из того что 5+1 бойцов сделают качественную систему не следует что через полтора года всех уволят. Заплатки, патчи и прочие диффы нужны и затем, чтобы ответить на постоянно меняющиеся требования к функционалу системы. Процесс разработки системы — это именно процесс — потенциально бесконечен. Ты это сам прекрасно знаешь. Так что бойцы без работы не останутся Зато клиент будет счастлив.

eao197,

IT>>Третье. [про бойцов]

E>[про сопровождение]

Как у нас с тобой мысли совпали...

Здравствуйте, Mika Soukhov, Вы писали:

MS>Это при условии того, что индус пришел в начальство раньше. А если позднее, когда ты уже работал Игорь, расскажи, как ты умеешь держать такую ненависть к азиатским народам и при этом работать в стране, которая не терпит рассковых предрассудков?

Здравствуйте, GlebZ, Вы писали:

V>>Отсюда имеем распространенные сейчас подходы, типа "писать надо так, чтобы и дебил разобрался". Мое имхо, далеко не обязательно так писать. Писать надо так, как это наиболее отвечает задаче. Уровень "дебила" тоже должен соответствовать задаче.
GZ>Вот с тем, что надо писать так, чтобы дебил разобрался, я абсолютно согласен.
GZ>Во-первых, библиотеки и решения пишутся не для собственного пользования. Существует люди которые видят и оценивают твой код. Точно так же будут люди которые будут использовать и работать с твоим кодом. И от того, как они оценят его и смогу быстро врубиться в него зависит долгота жизни этого кода. Я не один раз встречался с кодом который выбрасывался только из-за того, что в нем сам черт ногу сломит. Кстати, я встречался со случаями когда клиент просил показать код, чтобы просто оценить его качество.
GZ>Во-вторых, я заметил (и я думаю я не один), что существует зависимость от визуального качества кода, и количества ошибок который он несет. И к сожалению, я редко вижу код хорошего качества поскольку приходится обращать внимание не низкое качество визуализации кода.

Разве я сказал, что писать можно коряво? Речь шла о соответствии задачи и выбранного пути решения. Мне кажется, что ты озвучил одно из распространенных заблуждений. "Красивое оформление" и сложность кода — совершенно разные вещи. Они никак не связаны. Я полностью согласен с тем, что если код написан коряво, то его трудно читать. Код еще бывает сложно не читать, а "понять", для этого надо разбираться в технологии, которую этот код использует. Я против неоправданного примитивизма, который сейчас завоевывает все больше сторонников. Я видел достаточно проектов, которые были написаны "красиво" и легкочитаемо. Но сама "красивая" архитектура никак не соответствовала прикладной области. (например — реализация парсеров или автоматных моделей "в лоб"). Зато любой разбирался. Вот тебе красота ценой многократного проседания эффективности.

Здравствуйте, Mika Soukhov, Вы писали:

MS>Это при условии того, что индус пришел в начальство раньше. А если позднее, когда ты уже работал Игорь, расскажи, как ты умеешь держать такую ненависть к азиатским народам и при этом работать в стране, которая не терпит рассковых предрассудков?

Кто тебе сказал что я испытываю к индусам ненависть? К тому же испытвать что-либо к индусам или к их проф пригодности — это разные вещи, не находишь?

Здравствуйте, L.C.R., Вы писали:

LCR>Возможно это от плохого настроения, но вывод неправильный. Из того что 5+1 бойцов сделают качественную систему не следует что через полтора года всех уволят. Заплатки, патчи и прочие диффы нужны и затем, чтобы ответить на постоянно меняющиеся требования к функционалу системы. Процесс разработки системы — это именно процесс — потенциально бесконечен. Ты это сам прекрасно знаешь.

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

LCR>Так что бойцы без работы не останутся

Бойцы и так без работы не остануться

LCR> Зато клиент будет счастлив.

Вот это самый неопределённый момент. Самый простой способ сделать человека счастливым — это сначала отнять у него что-нибудь, а потом ему это вернуть. Проверено на практике миллион раз. Скорее всего группа из посредственностей будет радовать клиента гораздо чаще. А какая радость, сам подумай, будет от незаметно работающего без глюков софта? Знаешь как называют людей, которые ещё на стадии обсуждения говорят, что эта идея работать не будет или будет такие-то проблемы? Точно — troublemaker. А людей которые в последнюю минуту самоотверженно решают подобные проблемы? Правильно — hero. И что странно, практически никто не вспоминает, что эти проблемы были порождены ими же самими или при их попустительстве. Главное — результат.

Здравствуйте, flax, Вы писали:

F>1) Семантика ( смысловое описание информации)
F>2) AI (диллема между символами и мыслью ), а если вспомнить, что @"AI — это то, что сейчас нет",

Есть еще и другое определение AI

Искусственный интеллект — это то, чем занимаются, когда не хватает естественного.

Здравствуйте, Mika Soukhov, Вы писали:

MS>Это при условии того, что индус пришел в начальство раньше. А если позднее, когда ты уже работал Игорь, расскажи, как ты умеешь держать такую ненависть к азиатским народам и при этом работать в стране, которая не терпит рассковых предрассудков?
индус — это не национальность.
Это аббревиатура от

... IN
...  DO
    S = ...

По любимым кейвордам и именам переменных у низкоквалифицированных девелоперов.

IT,

IT>Если бойцы напишут правильную систему, то на её сопровождение нужен будет только один из них, остальные будут гонять в дум. Чтобы занять на сопровождении их всех, надо "очень профессионально" продумать это всё с самого начала.
Как то у тебя всё наизнанку вывернулось. Занять работой — не проблема. Сложность программного обеспечения не ограничена сверху. А вот ресурсы (в т.ч. и человеческие) ограничены.

IT>Вот это самый неопределённый момент. Самый простой способ сделать человека счастливым — это сначала отнять у него что-нибудь, а потом ему это вернуть. Проверено на практике миллион раз. Скорее всего группа из посредственностей будет радовать клиента гораздо чаще. А какая радость, сам подумай, будет от незаметно работающего без глюков софта?
Всё правильно, без несчастья счастья не познать. Но в данном случае опять вывод вывернут наизнанку. Всё ведь познаётся в сравнении... На моей памяти был следующий случай:

Клиент А покупает систему С1. По крайней мере раз в неделю клиент пользуется услугами (платными) вызова мальчиков. Мальчики чего-то чинят, но на следующей неделе опять что-то ломается, и приходится опять вызывать мальчиков. Минуты удовлетворённого облегчения сменялись досадой.

Наконец клиента А это достало. Он поднакопил денюшков и купил систему С2. С2 оказалась более стабильна и качественна. Информационной системе клиента уже ничего не мешало расти. И она росла. И поставщик С2 тоже учавствовал в росте. И от существующей системы у клиента была одна большая положительная эмоция. Короче, он был счастлив.

И теперь клиента А колбасой не заманишь на С1. Кроме всего прочего, был ещё один побочный эффект что А рекомендовал систему С2 своему другу Б. А как известно, рекомендация — лучшая реклама.

Группа посредственностей будет капать на мозг гораздо чаще — не радовать.

IT>Знаешь как называют людей, которые ещё на стадии обсуждения говорят, что эта идея работать не будет или будет такие-то проблемы? Точно — troublemaker.
Имхо "Пророки". Правильно подмечено — они никогда не пользовались благоговением народа.

IT>А людей которые в последнюю минуту самоотверженно решают подобные проблемы? Правильно — hero. И что странно, практически никто не вспоминает, что эти проблемы были порождены ими же самими или при их попустительстве. Главное — результат.
Часто таких героев называют "козлами". С соответсвующим уважением и почётом.

Да и вообще, вся индустрия IT — это борьба со своими же ветряными мельницами.

Здравствуйте, IT, Вы писали:

Все верно, но в условиях высокой конкуренции не работает. У клиентов тоже не лохи сидят. Хороших айтишников со стороны клиента тоже тяжко найти, но они есть. В следующий тендер героев турнут.

С уважением, Gleb.

Здравствуйте, Killen, Вы писали:

K>Если серьезно, то насчет десяти не уверен, но могу вспомнить несколько действительно важнейших:
K>1 — Действительно разумная логика.
При появлении способности к абстракции сразу появится способность к ошибке.

K>2 — сжатие данных
K> Тут нет предела совершенству. Раньше думали, что zip — это все, предел, пик (а может и не думали), а потом rar появился, который мог еще больше сжать zip файл. Уверен, появится метод еще лучше, который сможет любой rar сжать в несколько раз. Проблема в недостатке производительности и в нахождении и реализации хорошего алгоритма.
Zip и Rar — одинаковые LZW алгоритмы. Если хочешь посмотреть на настоящее качество сжатия, надыбай ha. Жутко тормозной, но зато круто сжимал. Не думаю что это важная и нерешенная задача.
K>3 — Защита данных.
K> Как сказал Ньютон, на каждое действие есть свое противодействие. Так же и везде. И в защите — на всякую защиту найдется свой ключ. Раньше методы были примитивными — замена алфавита другими символами, перемена мест символов в алфавите, метод Вижинера (хотя это не такой уж примитивный метод, но и его сломали), добавление числа к числовому аналогу текста, гаммирование, и проч. и проч. и проч. Тем не менее теоретически можно взломать любую систему защиты, вопрос только во времени, которого всегда мало. Создать такой метод шифрования, который даже теоретически невозможно будет взломать — вот третья задача.
Есть абсолютно защищенные шифры. Только это никому не нужно (особенно государству). Поэтому опять -1.
K>4 — Исправление багов и повышение производительности.
K> Чем больше программа, тем больше в ней ошибок, трат, недочетов и прочих недостатков, причем в геометрической прогрессии. Самым меньшим из всех зол является трата ресурсов, поэтому зачастую возникновение ошибок сводят к минимуму именно за счет "прожорливости" программы, создания огромных блоков отлавливания ошибок и т.д. Если бы windows был бы совершенством, он мог бы поместиться на дискету
Windows на дискетке? А это кому-то надо? Мне сейчас пару гиг на винды не жалко. Мне значительно важнее не сколько весит, а что она делает.
K>и выполняться в тысячи раз быстрее.
Тормозит в основном не Windows. Тормозят программы написанные под Windows(Unix, Linux и т.д). Может просто записать как нерешенную проблему как сделать так, чтобы любая программа выполнялась за 1 такт?
K>Для каждой цели есть свои средства, так для повышения производительности используется ассемблер, но на нем оччччень долго и трудоемко написать большой проект.
Ага, и пишут программы учитывая логику кэширования процессором памяти и очереди комманд.
K>Для них используется например Си, но Си забирает очень много производительности.
Очень много производительности? Ну-ну. Не читайте советских газет 15 летней давности.
K>Пожалуй, это пока все, что могу вспомнить. Остальное мелочно и незначительно, на фоне этих проблем
Все что написал, это не проблемы.
K>Сюда я редко захожу, поэтому ответы лучше на мыло: killen_co@e-mail.ru
А это здесь не принято. Если для общества, так для общества. Если личное(ну например личный спам), вот тогда на мыло.

С уважением, Gleb.

Здравствуйте, GlebZ, Вы писали:

GZ>Zip и Rar — одинаковые LZW алгоритмы. Если хочешь посмотреть на настоящее качество сжатия, надыбай ha. Жутко тормозной, но зато круто сжимал. Не думаю что это важная и нерешенная задача.

По-моему, ты не прав. Алгоритмы разные. Zip — это как минимум еще и алгоритм Deflate, который != LZW.

GZ>Есть абсолютно защищенные шифры. Только это никому не нужно (особенно государству). Поэтому опять -1.

Как известно из курса математики, таких шифров ровно один — шифр Шеннона (шифр с длиной ключа = длине текста). При длине ключа < длине текста шифр абсолютно защищенным не является.

GZ>Windows на дискетке? А это кому-то надо? Мне сейчас пару гиг на винды не жалко. Мне значительно важнее не сколько весит, а что она делает.
K>>и выполняться в тысячи раз быстрее.
GZ>Тормозит в основном не Windows. Тормозят программы написанные под Windows(Unix, Linux и т.д). Может просто записать как нерешенную проблему как сделать так, чтобы любая программа выполнялась за 1 такт?

Размер, кстати, не в последнюю очередь влияет на тормоза. Размер = Скорость * Время

Здравствуйте, GlebZ, Вы писали:
K>>Сюда я редко захожу, поэтому ответы лучше на мыло: killen_co@e-mail.ru
GZ>А это здесь не принято. Если для общества, так для общества. Если личное(ну например личный спам), вот тогда на мыло.