Форум » МЕТОДОЛОГИЯ-METHODOLOGY » Считалка про ПРОГРАММИСТОВ » Ответить

Считалка про ПРОГРАММИСТОВ

Vot: 10 программистов продукт решили сделать, Один спросил: "А деньги где?", - и их осталось 9. 9 программистов предстали перед боссом, Один из них не знал FoxPro, и их осталось 8. 8 программистов купили IBM, Один сказал: "Мак лучше!", - и их осталось 7. 7 программистов хотели help прочесть, У одного накрылся винт, и их осталось 6. 6 программистов пытались код понять, Один из них сошел с ума, и их осталось 5. 5 программистов купили CD-ROM, Один принес китайский диск - остались вчетвером. 4 программиста работали на Си, Один из них хвалил Паскаль, и их осталось 3. 3 программиста в сети играли в DOOM, Один чуть-чуть замешкался, и счет стал равен двум. Один устал загрузки ждать - остался лишь 1. 1 программист все взял под свой контроль, Но встретился с заказчиком, и их осталось 0. 0 программистов ругал сердитый шеф, Потом уволил одного, и стало их FF.(Примечание: FF = -1.) (не моё)

Ответов - 16

bne: Юзер - человек, наступающий на грабли Чайник - начинающий юзер, ни разу не наступавший на грабли и потому уверенный, что граблей не существует Ламер - юзер, регулярно наступающий на грабли, но по-прежнему уверенный что граблей не существует. Узкий специалист - юзер, в совершенстве владеющий наступанием на одни и те же грабли Широкий специалист - юзер, имеющий на лбу более двух шишек. Программер - тот, для кого в наступании на грабли важнее всего результат. Устав наступать на чужие грабли, изготавливает свои собственные. Продвинутый программер - программер, наступающий на каждые грабли не более двух раз. Копирайт - концепция, ограничивающая количество доступных для наступания граблей финансовыми возможностями юзера. Геймер - тот, для кого в наступании на грабли важнее всего процесс. Обычно не способен изготовить собственные грабли. Читер - разновидность геймера; наступает только на грабли с поролоновыми насадками на ручке и обычно не больше одного раза. Хакер - тот, кто способен наступить на грабли, даже если они спрятаны в сарай и заперты на замок. Хакер-идеалист - благородный борец за право каждого наступать на неограниченное количество граблей. Microsoft - корпорация, всемирный лидер по производству граблей Билл Гейтс - мифическое существо из программерского фольклора; злой дух - покровитель граблей. Апгрейд - процесс перманентной траты денег на покупку все новых граблей, каждые из которых бьют больнее предыдущих. Бета-версия - версия, в которой грабли видны невооруженным глазом. Релиз - версия, в которой грабли присыпаны листьями. Совместимость версий - принцип, позволяющий новым граблям попадать точно по шишке от предыдущих. Ассемблер - язык программирования, позволяющий наступать на грабли несколько миллионов раз в секунду. Локальная сеть - технология, позволяющая получить по лбу, даже когда на грабли наступает кто-то другой. Интернет - технология, позволяющая наступить на грабли, находящиеся на другой стороне земного шара. Сетевая конференция - технология, позволяющая каждому наступить не только на свои, но и на чужие грабли. Русские кодировки - подарочный набор набор граблей для пользователей интернета. Дружественный интерфейс - резиновая накладка на ручку граблей. Гибкий (настраиваемый) интерфейс - накладка на ручку граблей, которую можно двигать, подгоняя под высоту своего лба Графический интерфейс - грабли, позволяющие регулировать цвет и интенсивность искр после удара по лбу. Ненадежная система - грабли, которые бьют вас даже тогда когда вы на них не наступаете. Надежная система - грабли, которые бьют вас по лбу, даже когда вы стоите к ним спиной. Многозадачность - концепция, позволяющая наступать на несколько граблей одновременно. Объектно-ориентированное программирование - метод изготовления граблей по принципу матрешки. Мануал - книга, описывающая различные способы наступания на грабли. Никогда не используется ламерами и хакерами. Продвинутые программеры используют ее после того, как наступят на те же грабли во второй раз. Техподдержка - служба, дающая советы, что делать после наступания на грабли. Обычно первый ее совет - наступить на грабли еще раз и сравнить ощущения. http://vsiaco.org.ua/post138377258/?upd

bne: Михаил Левинштейн. Дух Физтеха Фрагмент "Поруганная вера Немца, как и положено, встречали в Пулково-2 с куском картона, на котором крупными буквами написаны были его имя и фамилия. Немец вышел к встречающим с рюкзаком за плечами, чемоданом в левой руке и книгой - в правой. Пожимая руки, он каждому доверчиво протягивал книгу и проникновенно говорил: " Моя Библия ". Именно так он именовал английское издание книги двух блестящих физтеховских теоретиков, Шкловского и Эфроса " Электронные свойства легированных полупроводников ". "Счастлив познакомиться с людьми, работающими рядом с этими замечательными физиками", - заявил энтузиаст. "Работавшими", - поправил кто-то из встречавших. "Все равно !,- воскликнул прозелит, - эта книга - моя библия. А ваш институт- моя Мекка. У вас в Иоффе работают лучшие теоретики и экспериментаторы мира !". Хотя у встречавших была своя точка зрения на затронутую тему, - возражать никто не стал. Утром за верующим заехали в гостиницу. На туалетном столике рядом с кроватью лежала книга Шкловского и Эфроса. " Каждый день я читаю эту великую книгу, - ворковал немец, - и каждый день нахожу в ней все новые и новые глубины". Поехали в институт, выпили кофе, стали талдычить " за науку ". Начали с обсуждения эксперимента, выполненного в Физтехе и в чем то противоречившего результатам, полученным в лаборатории гостя. Часа через два гость стал с понятным беспокойством поглядывать по сторонам, и наконец спросил прямо, где находится туалет. Нашлись желающие составить компанию, и группа товарищей направилась в конец коридора. Уже на подходе к храму, шагов за пять, немец стал проявлять признаки нервозности. Когда открылась дверь предбанника и глазам паломников предстала привычная картина: сломанный шкаф, пара мешков цемента в углу, несколько списанных приборов, сорванные краны etc., а запах заметно усилился, гость побледнел и попятился. Спутники ничего не замечали, и не прекращая научной дискуссии, начали приготовления к предвкушаемому процессу. Открылось дверь и в само святилище... Немец выбежал вон. Наши, полагая, что свободный человек в свободной стране волен делать все, что ему нравиться, сделали дело и вернулись в комнату, где велась дискуссия. Продолжения дискуссии, однако, не последовало. Гость сухо заявил, что ни одной экспериментальной работе, выполненной в "Иоффе" он отныне не доверяет. И предложил обсудить некий теоретический вопрос. Начали обсуждать теорию. Через час, однако же, природа взяла свое, и поклонник "Иоффе", извинившись, вышел. Вернувшись с окаменевшим лицом, немец долго мыл руки ( на счастье, в комнате оказался умывальник ), но когда в чистоте сердца предложили ему полотенце, он, только взглянув на когда-то белое вафельное полотнище, предпочел осушить руки изящными помахиваниями кистей. "Скажите, пожалуйста, - спросил неожиданно гость, - где именно работали в "Иоффе" гг. Шкловский и Эфрос?" - " Да здесь же, на этом этаже и работали", - простодушно ответили наши. " И, значит, они посещали..." Он умолк, не договорив. На следующее утро когда за немцем заехали, на столике у изголовья лежала обычная Библия на английском языке." http://lib.ru/NEWPROZA/LEVINSHTEIN/fti.txt

Vot: 1. Любая ошибка, которая может вкрасться в расчет, вкрадется в него. 2. Любая ошибка в любом расчете будет нацелена на причинение наибольшего вреда. 3. Во всякой формуле константы (особенно те, которые взяты из технических справочников) должны рассматриваться как переменные. 4. Самый важный размер на любой диаграмме или чертеже имеет наибольший шанс быть пропущенным. 5. Если опытная установка работает безукоризненно, все последующие будут неисправны. 6. Просьба об изменениях, которые совершенно необходимо внести в прибор, всегда поступает после того, как его изготовление почти закончено. 7. Части,которые просто нельзя собрать неправильно, все же будут собраны неправильно. 8. Все сроки обязательств по поставкам надо умножить на коэффициент 2,0. 9. Технические параметры приборов, заявляемые фирмой-изготовителем, надо умножить на коэффициент 0,5. 10. Ожидания покупателей новой машины надо умножить на коэффициент 0, 25. 11. Любое устройство, требующее наладки и регулировки обычно не поддается ни тому, ни другому. 12. Если за ошибку в расчете отвечает больше одного человека, виноватых не найти. 13. Одинаковые приборы, проверенные одинаковым способом, будут в эксплуатации вести себя совершенно по-разному. Ну и последнее: глупость пользователей не имеет точной верхней грани.


Молотобоец: 1. Не ходит в Интернет 2. Просит завести ему пароль минимум из двенадцати символов на всех раскладках и регистрах. 3. Ненавидит скринсейверы и фоновые картинки. 4. В игры играет только когда отделу АСУ нужен мальчик для битья в сетевом Quake. 5. Сам сносит винды и ставит их заново, драйвера тоже сам находит. 6. В свой обеденный перерыв и после работы бегает для отдела АСУ за пивом, воблой и сигаретами; при неполадках в локальной сети осуществляет снабжение непрерывно, до разрешения проблем. 7. Регулярно приносит CD с новой музыкой и фильмами, сам не слушает и не смотрит. 8. Объясняет руководству, что до сих пор не удосужился изложить отделу АСУ спецификацию на новый программный продукт, поэтому он еще и не готов. 9. Никогда не приходит за дискетами, а чтобы не увеличивать трафик в локальной сети носит данные с машины на машину на собственноручно купленных дискетах. ИСКЛЮЧЕНИЕ: когда данные нужны отделу АСУ - немедленно выкладывает их в нужную сетевую папку. 10. При работе с программами, сделанными в отделе АСУ, тонко чувствует,что программист имел в виду при их написании, не вводит некорректных данных, не мешает нормальной работе программ. 11. Твердо помнит, что во всем виноват Билл Гейтс и долбаный мастдай, а все что сделано отделом АСУ - круто и правильно! 12. Почувствовав, что отдел АСУ скучает, немедленно приходит и рассказывает анекдоты про тупых юзеров. Будучи посланным - вежливо прощается и немедленно уходит; появляется, как только в нем возникнет необходимость. 13. Юзера женского пола, прошедшие проверку и аттестацию отделом АСУ, деликатно и ненавязчиво предлагают услуги сексуального характера, после их оказания немедленно уходят, оставив пиво и сигареты.

bne: 26. Ученый диалог за ночлег. Любой странствующий монах мог остановиться в дзенском храме при условии, что он будет победителем тех, кто живет в этом храме. Если же он будет побежден, ему придется уйти. В одном храме на севере Японии жили два брата монаха. Старший брат учился, а младший был дурачком, да и к тому же еще и одноглазый. Однажды к ним зашел странствующий монах и попросился переночевать, предложив, в соответствии с обычаем, побеседовать о возвышенном учении. Старший брат, уставший от занятий за день, велел младшему выступить вместо себя. "Пойди и потребуй разговора в молчании",- научил он его. И так, младший брат и странник пошли к святыне и сели. Вскоре странник поднялся, подошел к старшему брату и сказал:"Твой младший брат удивительный парень. Он победил меня." "Перескажи мне диалог,"- попросил старший брат. "Сначала,- сказал странник,- я поднял один палец, символизируя просветленного Будду. Тогда твой брат поднял два пальца, символизируя Будду и его учение. Я поднял три пальца, символизируя Будду, его учение и его последователей, живущих гармонической жизнью. Тогда твой брат потряс сжатым кулаком у меня перед лицом, указывая, что все три произошли из одной реализации. Таким образом он победил, и я не имею права оставаться здесь." С этими словами странник ушел. "Где этот парень?"- спросил младший брат, вбегая к старшему. -Я понял от него, что ты победил в споре. -Ничего я не победил. Я хочу поколотить его. -Расскажи мне, о чем вы спорили,- попросил старший брат. -Ну, минуту он смотрел на меня, потом поднял один палец, оскорбляя меня намеком на то, что у меня один глаз. Так как он странник, то я подумал, что мне надо быть повежливее с ним. Поэтому я поднял два пальца, поздравляя его с тем, что у него два глаза. Тогда этот грубиян и негодяй поднял три пальца, намекая на то, что на нас двоих у нас только три глаза. Тогда я взбесился и стал колотить его, а он убежал. На этом все кончилось. "101 Дзенская история" Gthtdtltyj gj bplfyb. Paul Flesh Zen Bones. London-New York: Doubleday, 1957 Переводчик и редактор С. А. Кротков 1957 by Paul Reps. http://ki-moscow.narod.ru/litra/dzen101.htm

bne: "Высокая самооценка имеет множество градаций. Например, в своем исследовании мы обнаружили, что неустойчивая и поверхностная высокая самооценка ничем не отличаются от низкой самооценки", говорит Майкл Кернис. "Люди с неустойчивой высокой самооценкой компенсируют свою мнительность навязчивой тенденцией по любому поводу отстаивать и защищать чувство собственного достоинства. Эти исследования опубликованы в научном издании Journal of Personality. Соавторами работы также являются Чад Лейки и Уитни Хеппнер, аспиранты на факультете социальной психологии УД. По мнению Керниса, несмотря на сложную перспективу психиатрии, все же наблюдаются медленные, но уверенные сдвиги в том, как психологи понимают вопрос самооценки. Ранее считалось, что, чем выше человек оценивает себя, тем лучше. В последние годы, однако, эта теория трещит по всем швам, особенно, что касается агрессивного поведения. И к тому же, люди с высокой самооценкой иногда становятся просто невыносимыми, когда кто-то или что ставит под угрозу их "эго". Высокое самомнение до сих пор считается добродетелью, необходимой для счастливой и продуктивной жизни. Однако, ученые постепенно начинают подтачивать этот стереотип в надежде найти ту грань, где высокая самооценка приносит больше вреда, нежели пользы. На самом деле, есть множество видов высокой самооценки, где только некоторые из них можно справедливо отнести к позитивному психологическому функционированию. Высокая самооценка может принимать негативный окрас, когда сопровождается словесной защитой т.е. вспышками гнева. Обычно это происходит в условиях оспаривания мнения, взглядов, утверждений или системы ценностей того или иного индивидуума. Итак, чтобы проследить, отличаются ли респонденты с хрупкой самооценкой повышенной словесной агрессивностью по сравнению с респондентами со стабильной самооценкой, Кернис со своими коллегами провели эксперимент, разбив его на три этапа. В опыте участвовало сто студентов. На первом этапе участников попросили заполнить демографическую анкету, чтобы оценить уровень и параметры их самооценки. На втором этапе ученые анализировали уровень стабильности самооценки, поскольку, чем более неустойчивая или изменчивая самооценка, тем она более хрупкая. И на последнем этапе, чтобы определить так называемую "оборонительную вербализацию", исследователи провели структурное "интервью из жизненного опыта". "Результаты наших экспериментов в большей степени поддерживают многокомпонентную модель, которая демонстрирует четкое различие между неустойчивой и стабильной самооценкой", говорит Кернис. "Индивидуумы с низкой самооценкой или хрупкой высокой самооценкой обычно демонстрируют вербально-оборонительное поведение. Это происходит отчасти потому, что люди с низкой или хрупкой высокой самооценкой обычно преувеличивают степень потенциальной угрозы по сравнению с теми, у кого стабильная высокая самооценка, поэтому им приходится прикладывать больше усилий, чтобы сохранить чувство собственного достоинства. С другой стороны, люди со стабильной высокой самооценкой склонны принимать себя со всеми изъянами и недостатками. Чувствуя себя в большей степени безопасно, они редко обвиняют других, прибегая к вербальным защитным механизмам, и не оправдываются по поводу прошлых ошибок или угрожающих ситуаций. По мнению Керниса, ценность данного исследования заключается в том, что оно доказывает взаимосвязь повышенной вербальной оборонительности и низким уровнем психологического благополучия и удовлетворенности жизнью. "Повышенная оборонительность, как правило, свидетельствует не о здоровом психологическом восприятии, а о неуверенности, слабости и низко-оптимальном уровне функционирования в обществе", говорит Кернис. "Нет ничего крамольного в том, что люди хотят думать о себе хорошо. Но, когда это приобретает навязчивый характер, человек становится слишком чувствительным к критике окружающих и вынужден постоянно доказывать свою значимость. Такая самооценка, скорее, неустойчива, нежели стабильна и лишает человека всех своих психологических преимуществ". http://sci-lib.com/article115.html

bne: Советы служащим по правильному использованию ценного времени Системного Администратора. - Никогда не записывайте сообщения об ошибках. Просто нажмите "ОК" или перезапустите компьютер. СисАдмин любит угадывать, каким было сообщение об ошибке. - Когда говорите о своем компьютере, используйте такие термины, как "Ящик" и "Штука". - Когда вы получаете по почте EXE-файл, немедленно его открывайте. CисАдмин любит время от времени убедиться, что антивирусные программы работают нормально. - Когда отправляете кому-нибудь по почте документ, даже не думайте, какое программное обеспечение у адресатов. - Когда СисАдмин говорит, что сейчас придет, выйдете из системы и идите пить кофе. Для него не проблема вспомнить ваш пароль. - Когда вы зовете СисАдмина, чтобы он передвинул ваш компьютер, обязательно оставьте его похороненным под полутонной открыток, детских фотографий, чучел животных, сухих цветов и рекламных календариков. У СисАдмина нет своей жизни, и он находит ее, выхватывая мимолетные картины вашей. - Когда СисАдмин присылает вам почту, помеченную как "Очень важно" или "Примите Меры", сразу удаляйте ее. Он наверняка просто проверяет новую функцию почтовой программы. - Когда СисАдмин обедает у себя или в столовой, войдите и опорожните на него все проблемы и ожидайте немедленного ответа. СисАдмин существует только для того, чтобы обслуживать и всегда готов думать о починке компьютеров. - Когда СисАдмин выходит попить воды или прогуливается на улице, найдите его и задайте вопрос о компьютерах. Единственная цель его прогулок - разыскивать тех служащих, у которых нет электронной почты или телефона. - Отправляйте срочную почту ВСЮ В ВЕРХНЕМ РЕГИСТРЕ. Почтовый сервер вылавливает ее и помечает для внеочередной доставки. - Когда не работает копир, зовите СисАдмина. Это ведь тоже электроника, не так ли? - Когда ваш домашний компьютер сообщает "Нет сигнала в линии", позвоните СисАдмину. Он даже может исправлять проблемы с телефоном на расстоянии. - Когда ваш домашний ПК не в порядке, оставьте его на стуле СисАдмина без имени, без телефона, и без описания проблемы. Он очень любит хорошие мистификации. - Когда СисАдмин рассказывает вам по телефону порядок изменения настройки, читайте газету. СисАдмин на самом деле не имеет в виду, что вы должны что-то делать, он просто любит слушать свою речь. - Когда компания предлагает обучение в связи с апгрейдом операционной системы, не утруждайте себя посещением. СисАдмин всегда рядом, чтобы помочь. - Когда принтер не печатает, отправьте задание на печать заново, по меньшей мере 20 раз. Задания на печать часто исчезают в космос без причины. - Когда принтер все еще не печатает после 20 попыток, отправьте это задание на все принтеры офиса. Один из них должен работать. - Не пользуйтесь справкой. Справка для тех, кто не соображает, не так ли? - Если вы посещаете вечерние курсы по информатике, не стесняйтесь продемонстрировать свою растущую компетентность, обновив сетевые драйверы себе и всем коллегам. СисАдмин будет благодарен за сверхурочную работу, когда ему придется остаться до 2-3 часов ночи, исправляя все это. - Когда СисАдмин исправляет ваш компьютер в четверть второго, ешьте ваш гамбургер с сыром у него на глазах. Он работает лучше, когда у него слегка кружится голова от голода. - Когда СисАдмин спрашивает, не устанавливали ли вы новые программы, лгите. Никого не касается, что там у вас на компьютере, не так ли? - Если провод мыши задевает за фотографию вашей собаки, поднимите монитор и проденьте провод под ним. Эти прочные провода для мышей разработаны, чтобы выдерживать 20 килограмм компьютерного монитора, поставленного на них. - Если пробел на клавиатуре не работает, упрекайте СисАдмина в том, что вам не покупают новую. Черт, это же не ваша вина, что в ней под клавишами пол килограмма засохших крошек бутербродов, скрепок и больших липких пятен кетчупа. - Когда вы видит сообщение "Вы уверены?", нажимайте "Да" как можно быстрее. Черт, если бы вы не были уверены, вы бы этого не делали, не так ли? - Совершенно свободно говорите "Я ничего не знаю обо всей этой компьютерной ерунде". СисАдмина никогда не беспокоит, когда сферу его профессиональной компетенции называют ерундой. - Когда вам нужно добавить в принтер бумагу, зовите СисАдмина. Менять бумагу - это сугубо обслуживающая работа, и как Хьюлетт Паккард, так и Лексмарк рекомендуют, чтобы она проделывалась только сертифицированными сетевыми администраторами с уймой свободного времени. - Когда вы получаете 130-мегабайтный файл с фильмом, разошлите его всем, как срочное вложение. У СисАдмина полно дискового пространства и процессорной мощности на его новом почтовом сервере специально для таких важных вещей. - Даже не думайте о том, чтобы разбить большое задание на печать на несколько небольших. Не дай Бог, кто-нибудь украдет одну страничку из вашей 427-страничной таблицы Excel. - Когда вы встречаете СисАдмина в бакалее в воскресенье днем, задайте ему компьютерный вопрос. Он работает 24 часа в сутки, 7 дней в неделю, даже когда покупает в магазине туалетную бумагу и собачий корм. - Если ваш сын студент-программист, пусть приходит по выходным и делает свои проекты на вашем офисном компьютере. СисАдмин будет рядом и поможет, когда краденая копия Visual Basic 6.0 вашего сына опрокинет и убьет базу данных Access. - Когда вы приносите ваш новый домашний компьютер безымянной марки СисАдмину в офис для бесплатного ремонта, скажите, как срочно он должен его починить, чтобы вы могли снова играть в EverQuest. Он примется за него сразу потому, что в офисе у него так много свободного времени! Все равно все знают, что все, что он делает целыми днями - это шарит в Интернете. - Никогда не благодарите СисАдмина. Он обожает все ремонтировать и получать за это зарплату. Источник - sysadminday.com Перевод © 2002 Николай Газалов Редакция/адаптация © 2002 Александр Лысых, alexale@mail.ru P.S. Последняя пятница июля - международный день системных/сетевых администраторов.

ЗГТТ: 1. Ни один проект не заканчивается в установленные сроки, в пределах сметы, тем же составом работников, которые приступили к нему на начальном этапе. 2. Проект выполняется быстро до тех пор, пока не достигнет 90 % от полной готовности. Затем он остается на этой стадии навсегда. 3. Даже когда дела с проектом идут хорошо, все равно что-то должно идти плохо. Если кажется, что проектирование не может идти хуже, чем идет, значит оно пойдет еще хуже. 4. Если дела с проектом идут неплохо, значит ты что-то просмотрел. 5. Если по ходу реализации разрешается свободное изменения содержания проекта, то процент изменений превысит процент уже выполненного. 6. Ни один проект не может быть реализован без ошибок. Усилия по исправлению ошибок в проекте приводят к новым ошибкам, которые еще труднее обнаружить и устранить. 7. Ошибок не встречается только в проекте, который положен на полку. 8. Плохо спланированный проект займет в три раза больше времени, чем запланировано. Хорошо спланированный проект займет не намного меньше - всего лишь в два раза больше запланированного времени. 9. От глубины вашей дружбы с заказчиком и подрядчиком зависит количество замечаний, которые вы получите после выпуска проекта.

bne: Психбольница в руках пациентов или Почему высокие технологии сводят нас с ума и как восстановить душевное равновесие : Купер А. : Как противостоять натиску компьютерных технологий, проникающих в нашу жизнь c ужасающей скоростью? Наши телефоны, фотокамеры, автомобили... Купер цена : 250,00 руб издательство: Символ-Плюс (все книги издательства) дата выхода: ноябрь 2004 ISBN 5-93286-071-5 тираж 3000 экз. страниц: 336; масса, г.: 300; размеры (высота, ширина, толщина), см.: 22x17x2 обложка: мягкая; переводное издание оригинал: "The Inmates Are Running the Asylum" ISBN 0-672-31649-8 язык: английский год издания: 1999 Аннотация Как противостоять натиску компьютерных технологий, проникающих в нашу жизнь c ужасающей скоростью? Наши телефоны, фотокамеры, автомобили - все, что нас окружает, - автоматизируются, программируются, создаются людьми, которые, стремясь получить выгоду от применения микросхем, уклонились от своей прямой обязанности - делать эти продукты простыми в применении. И это не преувеличение, это реальность. Наша жизнь все больше концентрируется вокруг превратностей, странностей, решений и катастроф индустрии высоких технологий. Разработчики программ, устройств и технологий думают не так, как мы. Облеченные полномочиями исполнительные лица ни на что не влияют в мире высоких технологий - здесь всем заправляют инженеры. Мы разрешили пациентам завладеть психбольницей. Об этом рассказывает Алан Купер. Он предлагает новый подход к решению проблемы - проектирование взаимодействия продукта с пользователем должно предшествовать программированию. По его мнению, каждый доллар и каждый час, потраченные на проектирование взаимодействия, обернутся десятикратной экономией на этапе программирования. Отзывы специалистов От этого становится не по себе, но это правда. Персональные компьютеры породили новую взаимозависимость Новой Эры. Они позорят нас, раздражают нас, но мы продолжаем тратить на них деньги. Книга Алана Купера объясняет, почему все должно быть не так и что мы можем сделать для исправления ситуации. Чтение доставляет удовольствие и помогает спуститься с небес на землю. - Жан-Луи Гассе, президент Be, Inc. И впрямь пациенты. Людям пора проснуться и сказать "Все, с нас хватит!" Снова Алан Купер освещает нам путь. Чтение его книг следует сделать обязательным во всех компаниях, имеющих отношение к высоким технологиям и считающих, что они работают на благо клиентов. Нам нужно больше книг, подобных этой, больше людей, похожих на Алана Купера. - Дон Норман, Nielsen Norman Group; автор книги "The Invisible Computer" Если вы когда-нибудь задумывались, почему программы, написанные для компьютеров, и многочисленные электронные штучки ведут себя так, словно были созданы болваном или пытаются сделать болвана из вас, прочтите эту книгу. Книга Купера - это манифест о том, как повысить качество жизни в век, когда мы проводим много времени во взаимодействии с технологией. - Питер Хиршберг, президент Elemental Software Подход к проектированию, предлагаемый Купером, быстро завоевывает последователей, среди которых и такие клиенты, как Sun Microsystems, Coca-Cola, Compaq и Dow Jones. - Fast Company Magazine Целеориентированная методология проектирования Алана Купера, сосредотачивающая внимание на конкретных конечных пользователях (персонажах), привела команду проектировщиков к элегантному решению невероятно сложной проблемы проектирования пользовательского интерфейса. - Карен Ивенсон, руководитель инженерных разработок Sony Trans Com Браво! Живой и проникновенный трактат о проектировании взаимодействия от того, кто стоит у истоков. Раздавайте экземпляры друзьям, коллегам, своим клиентам. Об этой книге обязательно будут говорить, а возможно, и спорить. - Клемент Мок, основатель Archetype Studio, креативный директор Sapient Эта книга изменит ваши отношения с технологией, будь вы ее создатель или потребитель. Технология призвана помогать человеку, а не приводить его в замешательство. Это лучшая из прочитанных мною книг о проектировании взаимодействий: в ней Алан рассказывает, почему компьютеры неверно взаимодействуют с людьми и как излечить эту хроническую болезнь. Обязательная книга для всех, кто имеет дело с продуктами высоких технологий. - Джефф Хадфилд, главный редактор Visual Basic Programmer's Journal Мы находимся под сильным впечатлением от энтузиазма, профессионализма и методов работы нескольких команд Cooper Interaction Design, сотрудничающих с нами над перепроектированием центральных модулей R/3. - Маттиас Веринг, руководитель программы, SAP Если бы Алан Купер присутствовал на сказочном шествии короля через город, то первым бы заявил о том, что король голый, после чего показал бы всем, как создавать наряды привлекательные, экономичные и приятные в ношении. В этой книге Купер бросает вызов индустрии программного обеспечения на всех уровнях - от тех, кто пишет код, до высшего руководства, демонстрируя изъяны современ-ных программ и указывая на приемы проектирования, позволяющие исправить положение. Основываясь на своем богатом опыте в проектировании приложений, он излагает материал настолько ясно и практично, что книга может стать бесценным откровением для любого читателя - даже того, чей контакт с индустрией компьютерных приложений ограничен использованием продуктов, получивших название "танцующих медведей". - Терри Виноград, профессор информатики Стэнфордского университета Отличные программы создаются для пользователей. Работать с такими программами легко и приятно. Такая работа эффективна. Алан Купер четко показывает, что в массе своей программы создаются для программистов: на основе их догадок о потребностях пользователя, из любимых функций, индивидуальных особенностей стиля. Эта умная книга учит руководителей тому, что они должны знать, чтобы создавать системы, покоряющие рынок. Любой участник рынка - и самый удачливый и всего добившийся, и только еще полный надежд стать следующей сверхновой, поймет, что эта книга - одна из наиболее глубоких, практичных и полезных. - Ларри Кили, президент Doblin Group Сочетание острого ума автора и его высочайшего профессионализма делают эту книгу не только очень познавательной, но еще и весьма увлекательной. - Хайди Ройзен, Be, Inc. Алан Купер понимает разницу между интерфейсом и взаимодействием лучше, чем кто-либо из знакомых мне людей. Его идеи опираются на многолетний опыт в содействии разработке продуктов, элегантно и ненавязчиво проникающих в нашу жизнь. Он претворял свои идеи в жизнь много лет и теперь, наконец, нашел время превратить свой практический опыт в четкое описание задачи, с которой мы столкнулись, в методологию побега из психбольницы, которую мы с такой лю-бовью выстроили. Читайте дальше - и обретете свободу. - Пол Саффо, директор Института Будущего

bne: Жизненный цикл программиста У каждой профессии есть свой романтический период и есть период, когда она превращается в рутинную. Быть шофером в начале прошлого века было трудно и почетно. Сегодня автомобиль может водить любой желающий, а в большинстве районов США жизнь без автомобиля практически невозможна. Так профессия шофера прошла полный цикл от интеллектуальной и романтической до бытовой и повседневной за какие-то 60 лет. Цикл профессии авиапилота тоже близится к окончанию и займет те же 60 лет. Но время ускоряется, и новые профессии имеют гораздо более короткий цикл. Особенно это верно по отношению к профессиям, связанным с информационными технологиями. Так получилось, что время моей жизни практически совпало с жизненным циклом моей профессии. Я – программист. Сами компьютеры появились в 40-х годах (и не надо здесь вспоминать ерунду про дочку Байрона), то есть в то же десятилетие, когда я родился. В этой статье я хочу, вспоминая свою профессиональную жизнь, напомнить, как менялась профессия программиста. Когда я школьником учился программировать на М-20, в СССР программистами были известные математики, на ходу выдумывавшие то, чему сейчас учат в школе. В группе программистов Института Теоретической и Экспериментальной Физики, где для вычислительных работ ядерной физики стояла эта самая М-20, придумали массивы, списки, необходимость использования подпрограмм и многое другое. Один из моих учителей, Г.М. Адельсон-Вельский придумал хэш память. Подробности можно найти в книге другого моего учителя – А.С. Кронрода «Беседы о программировании». Еще до Дийкстры основные принципы структурного программирования были изложены А.Л. Брудно в книге «Программирование в содержательных обозначениях». Там же была создана первая шахматная программа. А ведь в то время программировали в кодах, память под программы и переменные распределяли своими руками, и известны случаи, когда на одно и то же место грузились разные подпрограммы, и всегда работала только последняя. Всерьез была распространена так называемая «польская игра», когда надо было уложить заданный алгоритм в минимальное число ячеек памяти. В итоге тогда шахматная программа ИТЭФ, предшественница «Каиссы», умещалась в памяти М-20, а именно в 4096 ячейках, каждая из которых имела 48 разрядов (теперь это называют битами). Где-то рядом уже существовал Алгол-60, но им «настоящие» программисты не пользовались, поскольку техники отладки практически не было. Чуть позже большую популярность получила статья «Почему настоящие программисты не пишут на Фортране». Мои студенческие годы пришлись на целый ряд советских машин – Раздан-3 , Минск 1, 2, 22, 32, Урал-14, все из которых имели пульт, за которым сидели программисты, а программы и данные вводились с перфокарт или с перфолент. АЦПУ - устройство «широкой» печати - появилось только в конце 1960-х. Для того чтобы быстрее писать программы для этих машин мы сами разрабатывали операционные системы. Тут уже требовалась высокая техника программирования, поскольку эффективность операционной системы была необходима для самой возможности ее использования. Рассказывают, что в операционной системе «Пульт», написанной в Вычислительном Центре АН СССР для БЭСМ-6, был счетчик ошибок оператора, и при достижении некоторого порога система выдавал «вежливое» сообщение «А если ты – дурак, то не садись за “Пульт”». Когда директор ВЦ академик А. Дородницын инспектировал систему, он понажимал несколько раз случайные кнопки и был крайне огорчен полученным результатом. ........ Подводя итоги, я хочу показать, как логика развития информационных технологий изменила характер моей профессии. Говорить о профессии программиста вообще можно, но она столь же не конкретна, как и профессия строителя. Человек, кладущий кирпичи, и человек, создающий большие архитектурные проекты, в равной степени могут называться строителями, но это абсолютно разные профессии. В моем возрасте класть кирпичи уже не эффективно – не хватает скорости мысли, но, с другой стороны, опыт работы позволяет абстрагироваться от мелочей и рассматривать проблемы с системной точки зрения. Для моих американских коллег такой подход очевиден, здесь же многие считают его верхоглядством. Я давно считаю само собой разумеющимся, что смогу реализовать любой алгоритм. Я имею довольно большой инструментальный набор и знаю, каким инструментом когда пользоваться. Мне не приходится задумываться над тем, как писать циклы, и так далее. Все это дает возможность, думая над программой, делать это с другого уровня. Приходящая же в профессию молодежь, не имеет такого запаса. И не столько потому, что глупее, а потому, что их не так учат. В моей молодости обучение программированию в институтах было вообще смешным – изучались только синтаксисы разных языков на простейших программах. Сейчас дело обстоит чуть получше, но я не слышал, чтобы во время сдачи курсовой или дипломной работы студенту на ходу меняли техническое задание. А мне в жизни приходилось, сдавая большую систему с удивлением узнавать об изменении формата входных данных. Я считаю такую ситуацию нормальной, а молодые программисты – издевательством. Они не понимают, что если заказчик меняет требования к уже почти готовой системе, это означает, что система ему нравится. Если система ему не нравится, он вздохнет, заплатит за нее и про нее забудет. Все молодые ребята, приходящие ко мне обладают одним и тем же недостатком. Они устремлены к тому, чтобы их часть программы заработала как можно быстрее, думая, что это – успешный конец работы. Никто до меня их не научил, что работающая программа – это только начало. Дальше, в ходе ее использования будут возникать все новые требования, и программу придется непрерывно менять. Поэтому изначально в нее должна быть заложена эластичность, без которой вносить изменения в программу будет крайне сложно. Кроме того, инструментальные средства, которые они используют, становятся все более крупными, и мало кто понимает, как эти средства организованы внутри, по каким принципам они работают. Это и не требуется, если нужно только чуть-чуть подстроить такие средства, но при создании больших систем отсутствие такого понимания может вести к большим проблемам, начиная с неэффективности и кончая полной неработоспособностью. А понять внутреннюю организацию сложных систем можно только одним способом – самому сделать что-то подобное, пусть и гораздо более простое. Но я не слышал, чтобы студентам задавали в качестве курсовой работы создание простой операционной системы или системы управления базами данных. В итоге профессия программиста меняет свой характер. Если раньше программисты знали свою программу досконально, то теперь в лучшем случае они умеют эффективно использовать то или иное инструментальное средство. Появились вообще странные на мой вкус термины как программисты на PHP и HTML. Я пишу эту статью к своему 60-му дню рождения, возраст пенсионный, и, похоже, кончается не только мой жизненный цикл, но и жизненный цикл той творческой профессии, которой я занимался всю жизнь, и которая называлась профессией программиста. Сейчас профессия осталась, но, как и профессия шофера, она не требует творчества и особых знаний, а только определенных навыков. Программирование из искусства становится ремеслом, и я счастлив, что всю жизнь занимался программированием, пока это было так же интересно и почетно, как пилотировать самолеты во времена А. Экзюпери. 20 августа 2008, 08:08 Михаил Донской

bne: Если Вам приснилось, что Вы работаете с компьютером, то в реальной жизни Вас ждут изменения в профессиональной деятельности, которые потребуют от Вас большей ответственности. Если же Вы не умеете работать на компьютере, то наяву Вы не сможете справиться с возложенными на Вас обязанностями. Видеть компьютер последней модели предупреждает, что Вашему желанию не суждено осуществиться из-за внешних обстоятельств. Играть в компьютерную игру является предупреждением, что Вы слишком увлечены собой и можете потерять друзей. Если во сне Ваш компьютер завис, то Вы будете недовольны действиями своего начальства. Открыть или закрыть во сне файл - свидетельство того, что ваши планы могут мгновенно рухнуть из-за малейшей неосторожности. Узнать во сне имя файла - предвестие того, что в скором времени вам станет известна служебная информация, которая значительно поможет вашей карьере. Скопировать во сне файл на диск - знак того, что вы стремитесь всеми силами привлечь к себе внимание, но делаете слишком много неверных ходов, поэтому вам не удается добиться признания. Удалить ненужные файлы с дискеты означает, что, несмотря на все трудности, вам удастся одержать победу над вашими недоброжелателями. Если же файлы были нужные, а вам приснилось, что вы их удалили, то это значит, что вы напрасно обидели вашего друга: он вам желает только добра. ;-))))

bne: Правила Ашманова Автор: Игорь Ашманов: управляющий партнер и генеральный директор компании «Ашманов и Партнеры» -------------------------------------------------------------------------------- Данный свод высказываний предназначен для руководителей, которым волей судеб пришлось заниматься новым для себя делом — управлять тем или иным «программистским» проектом (созданием информационной системы предприятия, разработкой сайта, и т. п.). Опытному человеку сказанное ниже может показаться набором простых и давно известных истин. Я и не собираюсь претендовать на авторство всех приведенных ниже правил. Однако начинающие менеджеры программных проектов зачастую не знают простейших вещей — например, того простого факта, что нельзя верить срокам, называемым программистами. Воинские уставы и Правила дорожного движения также выглядят просто, но они «писаны кровью». Много раз видели мы срыв сроков, провал проектов. Видели бизнесменов, с готовностью вкладывавших деньги в новую технологию, поражающую воображение — без понимания рынка, бизнес-планов и даже примерных результатов и сроков работ. Я и сам совершал множество подобных ошибок за 15 лет работы в индустрии производства программного обеспечения. Вот эти простейшие вещи и собраны здесь в виде свода правил. Вот самое первое из них: Первое правило Ашманова. Не бывает технических проблем. Бывают только человеческие, то есть организационные. Я не даю здесь технических советов относительно управления проектами, правил планирования и документирования, процедур тестирования и выпуска. Обо всем этом написаны горы специальной литературы, в том числе классическая книга Фредерика Брукса «Мифический человеко-месяц». Однако должностные инструкции и правильные процедуры — далеко не всё. При запуске проекта руководитель в первую очередь вступает в человеческие отношения с коллегами, исполнителями, подчиненными. Эти отношения сложны, непривычны и часто могут просто поставить в тупик, если не знать всего нескольких простых правил. Об управлении программистами Я лично очень уважаю и люблю разработчиков программного обеспечения — программистов, однако в обращении с ними нужно соблюдать осторожность и определенные правила. Управление программистами - не магия. Управлять программным проектом может даже гуманитарий. Но для этого обязательно нужно вообще уметь управлять людьми и проектами. Как и в любой отрасли, менеджеру достаточно знать некоторые особенности технологического процесса и не поддаваться «мифам индустрии». Всё остальное зависит от обычного умения менеджера наладить работу. Мифы. Управление программистами имеет особенности, осложненные мифами и иллюзиями вокруг программирования. Эти мифы охотно поддерживаются разработчиками и продавцами компьютерных услуг. Основной причиной мифов является противоречие между очевидной интеллектуальностью и сложностью работы с одной стороны, и совершенно обычными свойствами персонала и проектов — с другой стороны. Независимость от мифов приходит с опытом и знанием. Распространенные мифы о разработке программного обеспечения Миф об уникальной специфике программного обеспечения. Производство программного обеспечения не является особым бизнесом, что бы там ни говорили сами разработчики или продавцы информационных систем. Оно не более особенное, чем пищевая промышленность или косметология. Законы развития и окупаемости проектов при разработке ПО, интернет-сайтов и корпоративных информационных систем — те же самые, что и везде. Поэтому разговоры об уникальности разработчиков ПО, специфике управления программистским проектом, особых путях бизнеса — всегда очень подозрительны. Миф о невероятной сложности программирования. На самом деле процесс создания современной программы не сложнее и не более творческий, чем процесс создания современного автомобиля, рекламного ролика или лекарства. В этих индустриях давно наведен порядок, не мешающий творчеству. Миф о величии программиста. Разработчик программного обеспечения — не оракул, прорицания которого бизнесмен должен слушать с восхищением. Действительно, внешне любой, даже средний программист выглядит, как взрослый, умный и ответственный человек — он высокообразован, занимается сложной умственной работой, владеет терминологией, умеет поставить задачу и обосновать запрос на выделение ресурсов. При этом на деле он постоянно проявляет себя как малолетний двоечник — не говорит всей правды, ошибается со сроками, срывает проекты, сворачивает с прямого пути и развлекается за счет работодателя. Если в проекте разработчики играют первую скрипку, вероятность краха проекта — высока. Верный признак такого положения - когда менеджер высокого уровня, непрограммист, с заметной неуверенностью рассказывает о том, что всё идет нормально и текущий этап проекта представляет собой важные внутренние технические улучшения, которые на следующих этапах позволят осуществить прорыв. Нужно помнить, что разработчик ПО — это инженер, а в бизнесе высоких технологий выигрывают не инженеры, а бизнесмены и менеджеры. Как и везде. Миф о магической силе технологии. Новая, сложная, впечатляющая технология не обязательно приведет к успеху. К счастью, сегодня это уже не нужно никому специально доказывать. Всякая технология может стать успешным продуктом, а может просто привести к растрате денег инвестора. Источники успеха проекта всегда лежат вне сферы технологий — в сфере бизнеса. Кроме того, нужно помнить, что действительно уникальные технологии возникают очень редко, и с большой вероятностью в настоящий момент точно такая технология уже обсуждается, разрабатывается или даже продается где-то еще. Правила, которые полезно знать менеджеру Правило 2. Технический жаргон ничего не значит. Программисты используют весьма развитый технический жаргон, в том числе на совещаниях и в докладных записках. Известно, что любой жаргон служит узнаванию своих и запутыванию чужих. Жаргон программистов — не исключение, а враждебным чужаком для программиста часто служит его начальство. На самом деле технический жаргон в большинстве случаев не нужен и не несет дополнительного знания. Всё, что нужно знать о проекте, может быть выражено обычным деловым языком — языком бизнес-плана, функционального описания, сетевого графика, рекламного проспекта. Правило 3. Разработчики всегда называют неверные сроки. Нельзя верить срокам, которые называют программисты. Обычно их следует умножать на Пи. Иногда (редко) — делить на Пи. Выбор правильного действия руководителя над называемыми сроками зависит от личности разработчика. Это знание приходит к менеджеру только после нескольких экспериментов именно с этим разработчиком. Правило 4. Разработчику свойственен врожденный оптимизм. Средний разработчик всегда добросовестно заблуждается относительно трудоемкости задачи, обычно в меньшую сторону, поэтому его нельзя уличить или разоблачить. Более того, он никогда не учится на ошибках и постоянно повторяет одну и ту же ошибку занижения сроков, поэтому его бесполезно стыдить или воспитывать. Категорически нельзя рассчитывать, что уж на этот раз битый жизнью разработчик наконец-то называет реальные сроки. Типичный признак необъезженного разработчика-оптимиста — самоуверенность и горячность, стремление пойти и сделать, а не сесть и запланировать. Правило 5. Программист испытывает страсть к обобщению. Программист всегда всеми силами стремится сделать работу наиболее общим способом, чтобы потом только настраивать и прилаживать готовую систему. В этом — суть программирования и его сила. И в этом же — серьезная угроза бизнесу. Если дать разработчику волю, разработка общей платформы отнимет 100% времени и денег, и продукт никогда не выйдет на рынок. Поэтому программирование в наиболее общем виде нужно категорически запрещать. Верным признаком страсти к обобщению является планирование создания мощных ядер и наиболее общих платформ со сроками исполнения больше года. Баланс между обобщением и текущими требованиями рынка достигается опытом и соображениями бизнеса. Программистам доверять здесь абсолютно бессмысленно, как бессмысленно обсуждать с пьяницей семейный бюджет. Правило 6. Нельзя делать «по-хорошему». Всякий программист свою страсть к обобщению оправдывает похвальным желанием наконец-то всё сделать по-хорошему. Точно так же системный администратор всегда просит денег на самую лучшую технику и самое дорогое программное обеспечение от Oracle. Делать по-хорошему — теоретически неправильно и практически вредно для бизнеса. Нужно делать так, чтобы всё работало, удовлетворяло клиентов (ровно на уровне цены продукта) и бизнес развивался. Верный признак работы в стиле «по-хорошему» — упорная работа с «ядром», задержки с реализацией конкретной запланированной функциональности и срыв сроков выхода продукта. Правило 7. Приминание травы может отнять любое количество времени. Программист всегда стремится удовлетворить свою потребность в вооруженности — максимально обустроить рабочее место, то есть создать инструментарий, установить самое последнее программное обеспечение, самую современную технику. Если дать ему волю, он потратит на это 100% рабочего времени, причем сумеет доказать начальству необходимость такой работы. Верный признак такого перманентного обустройства — полуразобранные компьютеры на рабочих местах и необычные, нестандартные программы на этих компьютерах. Правило 8. Разработчик не интересуется бизнесом, он — типичный автор. Разработчик в среднем не стремится помочь организовать и развить бизнес, именно поэтому он не любит тестирования, считает пользователей идиотами, поэтому его трудно заставить документировать и поддерживать уже сделанные системы и программы. Истинные личные мотивы большинства разработчиков — авторские, то есть включают интересную работу, хорошие гонорары и известность. Низовой разработчик может не иметь даже и авторских амбиций, и интересоваться только работой и зарплатой. Успех продукта или компании в смысле роста прибыли интересует разработчика только опосредованно. Это нормально, так как авторские мотивы — очень мощные и их можно правильно использовать с большой пользой для компании. Выводы Приходится работать с тем, что есть. Из сказанного вытекает практическая невозможность перевоспитания разработчиков, системных администраторов и средних технических менеджеров в деловом духе. Этого и не требуется. Вместо перевоспитания нужно понимание мотивов и привычек, и работающие процедуры планирования, исполнения и контроля, сохраняющие свободу мышления и оставляющие простор для творчества. Схемы мотивации также должны учитывать авторские мотивы и врожденный оптимизм разработчика (например, из этого общего принципа легко выводится недопустимость штрафов за срыв сроков). http://it4business.ru/?p=124 СМОТРИ ТАКЖЕ http://www.profyclub.org/articles/295/3286

пао:

bne: Гарвард. Объявлены лауреаты Шнобелевской премии за 2009 год www.k2kapital.com 02.10.2009 Премия-пародия на всемирно известную Нобелевскую премию - Ig Nobel Prize (Шнобелевская или Антинобелевская премия – обнародовала имена лауреатов за 2009 года за научные достижения, «которые сначала вызывают смех, а затем заставляют задуматься». В нынешнем году лауреатами стали 72-летний японский ученый Фумиаки Тагути и двое его китайских коллег. Разработанный ими метод борьбы с кухонными отходами с помощью бактерий, живущих в фекалиях панды, обошел авторов других научных трудов, чья бесполезность является основным правилом участия. Награда также была вручена группе из Швейцарии, которая экспериментальным способом доказала, что и пустая и полная пивные бутылки при ударе об голову наносят серьезный вред человеку. Но «пустая бутылка гораздо крепче из-за давления, создаваемого жидкостью, в данном случае пивом, вкупе с ее насыщенностью углекислым газом. Это делает полную бутылку хрупкой». Лауреатами премии также стали фермеры, доказавшие, что корова будет давать больше молока, если у нее есть кличка; ученый, выяснивший, почему не переворачиваются; мексиканские, получающие бриллианты из текилы, а также американцы, получившие премию в области медицины за защитную маску для дыхания на двоих, в которую мгновенно превращается бюстгальтер. Премии в области литературы удостоились ирландские полицейские. Они выписали более 50 уведомлений о нарушении правил дорожного движения мифическим "водителям-лихачам", которых они принимали за одушевленных лиц по имени Право Язды (Prawo Jazdy – водительское удостоверения) с польскими правами на вождение автомобиля. Ig Nobel Prize была учреждена в 1991 году Марком Абрахамсом и юмористическим журналом "Анналы невероятных исследований". Шуточная церемония награждения проводится в одном из лекционных залов Гарварда в начале октября, т.е. именно тогда, когда называются лауреаты Нобелевской премии. Награды премии вручаются в тех же областях, что и награды "нобелевки".

bne: Инструкции для авторов Джек Эвинг В тот журнал, который я возглавляю, как правило, принимаются статьи, которые никуда больше нельзя протолкнуть. Если вам вернули статью из очередного журнала (с маленькой буквы), прогладьте её утюгом и пришлите в наш Журнал (с большой буквы). Оформление рукописи Текст : Рукопись должна быть напечатана на стандартных листах пергамента размером 8 1/2 х 11 дюймов. Печатать следует не больше чем на двух сторонах листа, каждый параграф начиная с новой страницы. Оставляйте с двух сторон страницы поля по 4—4 1/2 дюйма. Автор должен пользоваться ясным, прозрачным, кристальным английским языком, применяя предпочтительно не менее чем двусложные слова, состоящие не более чем из четырех букв. Не следует употреблять слов, понятных вашим коллегам. Например, не пишите «сокращённый», а пишите «редуцированный», не «изменённый», а «модифицированный». Не употребляйте предложений длиннее 120 слов, не включив в них по крайней мере одного глагола или деепричастия. Во всём, что касается правописания, употребления заглавных букв и прочего, следуйте словарю Вэбстера. Редактор всё равно всё переделает. Сокр. д. б. свед. к мин. Не изготовляйте таблиц из данных, которые можно перечислить в тексте. Не перечисляйте в тексте данных, из которых можно сделать таблицу. Не выражайте отношения в мг/кг. Литературные ссылки. Назовите автора, его адрес и номер тома. По возможности год. (Вместо фамилий авторов можно приводить их прозвища, если они общеизвестны.) Иллюстрации. Их можно изготовлять разными способами. Особенной чёткости не требуется. На обороте каждой фотографии кратко изложите инструкции для редактора (избегайте непечатных слов). Выводы. По возможности выводы должны быть короче основного текста и представляться в форме, допускающей их использование в качестве аннотаций для реферативных сборников. [48] Инструкция для читателя научных статей Во всех основных разделах современной научной работы – во введении, изложении экспериментальных результатов и т. д. – встречаются традиционные, общеупотребительные выражения. Ниже мы раскрываем их тайный смысл (в скобках). Введение «Хорошо известно, что…» ( Я не удосужился найти ссылку на работу, в которой об этом было сказано первый раз. ) «Имеет огромное теоретическое и практическое значение». ( Мне лично это кажется интересным. ) «Поскольку не удалось ответить сразу на все эти вопросы…» ( Эксперимент провалился, но печатную работу я всё же сделаю. ) «Был развит новый подход…» ( Бенджамен Ф. Мейсснер использовал этот подход по меньшей мере 30 лет тому назад. ) «Сначала изложим теорию…» ( Все выкладки, которые я успел сделать вчера вечером. ) «Очевидно…» ( Я этого не проверял, но… ) «Эта работа была выполнена четыре года тому назад…» ( Нового материала для доклада у меня не было, а поехать на конференцию очень хотелось. ) Описание экспериментальной методики «При создании этой установки мы рассчитывали получить следующие характеристики…» ( Такие характеристики получились случайно, когда нам удалось, наконец, заставить установку начать работать. ) «Поставленной цели мы добились…» ( С серийными образцами вышли кое-какие неприятности, но экспериментальный прототип работает прекрасно. ) «Был выбран сплав висмута со свинцом, поскольку именно для него ожидаемый эффект должен был проявиться наиболее отчётливо». ( Другого сплава у нас вообще не было. ) «…прямым методом…» ( С помощью грубой силы. ) «Для детального исследования мы выбрали три образца». ( Результаты, полученные на остальных двадцати образцах, не лезли ни в какие ворота. ) «…был случайно слегка повреждён во время работы…» ( Уронили на пол. ) «…обращались с исключительной осторожностью…» ( Не уронили на пол. ) «Автоматическое устройство…» ( Имеет выключатель. ) «…схема на транзисторах…» ( Есть полупроводниковый диод. ) «…полупортативный…» ( Снабжён ручкой. ) «…портативный…» ( Снабжён двумя ручками. ) Изложение результатов «Типичные результаты приведены на…» ( Приведены лучшие результаты. ) «Хотя при репродуцировании детали были искажены, на исходной микрофотографии ясно видно…» ( На исходной микрофотографии видно то же самое. ) «Параметры установки были существенно улучшены…» ( По сравнению с паршивой прошлогодней моделью. ) «Ясно, что потребуется большая дополнительная работа, прежде чем мы поймём…» ( Я этого не понимаю. ) «Согласие теоретической кривой с экспериментом: Блестящее… ( Разумное… ) Хорошее… ( Плохое… ) Удовлетворительное… ( Сомнительное… ) Разумное… ( Вымышленное… ) Удовлетворительное, если принять во внимание приближения, сделанные при анализе…» ( Согласие вообще отсутствует. ) «Эти результаты будут опубликованы позднее…» ( Либо будут, либо нет. ) «Наиболее надёжные результаты были получены Джонсом…» ( Это мой дипломник. ) Обсуждение результатов «На этот счёт существует единодушное мнение…» ( Я знаю ещё двух ребят, которые придерживаются того же мнения. ) «Можно поспорить с тем, что…» ( Я сам придумал это возражение, потому что на него у меня есть хороший ответ. ) «Справедливо по порядку величины…» ( Несправедливо… ) «Можно надеяться, что эта работа стимулирует дальнейший прогресс в рассматриваемой области…» ( Эта работа ничего особенного собой не представляет, но то же самое можно сказать и обо всех остальных работах, написанных на эту жалкую тему. ) «Наше исследование показало перспективность этого подхода…» ( Ничего пока не получилось, но мы хотим, чтобы правительство отпустило нужные средства. ) Благодарности «Я благодарен Джону Смиту за помощь в экспериментах и Джону Брауну за ценное обсуждение». ( Смит получил все результаты, а Браун объяснил, что они значат. ) [49]

bne: Из статьи А.Н.Горбаня и Г.С.Яблонского “Взаимодействие математики и химии как общение учёных”: “...пусть сотрудничество состоялось и получен важный результат. Однако и в этом случае возможен конфликт – “Делёж”, когда каждый переоценивает свой вклад, считая труд другого малопрофессиональным. Утверждая, что другой не решил бы задачу, в каком-то смысле правы оба: результат родился в ситуации взаимодействия и ей принадлежит. Химик мог бы сказать, что любой математик помог бы ему, а математик возразит, что любой химик мог бы дать ему задачу. И это зачастую правда, но обоюдоострая. Можно заменить обоих партнёров, уникальным является их взаимодействие. Именно оно порождает результат. Именно оно (а не кто-то из партнёров) обеспечивает новизну результата, его творческий момент. Описанные конфликты – “личностные”. Но все они в той или иной степени и “надличностные”, ибо корни их уходят в почву взаимодействующих наук, т.е. в традиционную логику их развития”. <...> “Оговоримся: конфликт – это не обязательно ссора или склока. Наличие противоположных линий при взаимодействии само по себе создает конфликтную (или, точнее говоря, чреватую конфликтом) ситуацию. Если партнёры смогут найти содержательный выход, то конфликт между ними разрешится, не перерастая в склоку. Ею чаще всего оборачивается конфликт “Делёж”. Что же нужно противопоставить склоке? “Принцип сочувствия”, сформулированный С.Мейеном? Или же правило “Ставь интересы партнера выше собственных!”, провозглашенное на одной из встреч математиков и биологов? Мы, например, в своей практике иногда используем принцип открытого авторства. Суть его в том, что некоторые постановки задач сообщаются людям, связанным в науке долгими доверительными отношениями. А потом – как получится. Автором будет тот, кто хоть как-то участвует в работе. Обиды исключает сам психологический климат группы. Но мы отчётливо осознаём и весь связанный с этим риск. Этические правила гораздо легче декларировать, чем выполнять. Конфликт коренится в самой сути взаимодействия. Даже если конфликт и разрешится продуктивно, исходные противоречия, скорее всего, не устранятся. Конфликт будет возникать вновь и вновь”. <...> “Итак, взаимодействие чревато конфликтами, преодоление, разрешение их возможно лишь на основе сотрудничества. Но сотрудничество – это не замазывание разногласий. Необходимо сотрудничать, не поступаясь различиями, сотрудничать благодаря различиям, ориентируясь не на “описание” и “приложение”, а на новые смыслы: Подобно голосам на дальнем расстоянье, Когда их смутный хор един, как тьма и свет, Перекликаются звук, запах, форма, цвет, Глубокий, тёмный смысл обретшие в слиянье. Шарль Бодлер. “Соответствия”. (Из сборника научных трудов “Взаимодействие наук как фактор их развития”. – Новосибирск, “Наука”, 1983.) http://magazines.russ.ru/din/2006/7/le46-pr.html



полная версия страницы