Начала читать "Oracle для профессионалов" Тома Кайта. Зацепила такая история:
Я видел, как разработчики в СУБД Oracle 8i создавали процессы-демоны, читающие сообщения из программных каналов (это механизм межпроцессорного взаимодействия в СУБД). Процессы-демоны выполняли операторы SQL, содержавшиеся в прочитанных из программного канала сообщениях, и фиксировали сделанное.
...
В версиях Oracle до Oracle 8i это был приемлимый (и практически единственный) способ реализации описанной функции. Когда я рассказал разработчикам об автономных транзакциях, поддерживаемых СУБД, они очень расстроились. Автономные транзакции, реализуемые добавлением единственной строки кода, делали то же, что вся их система.
Положительным моментом оказалось то, что можно было выкинуть существенную часть кода и не поддерживать его в дальнейшем. Кроме того, система стала быстрее и проще для понимания. Но их это все равно мало радовало, - очень уж много времени было потрачено на изобретение велосипеда.
Так вот, к чему это я - пока бродишь по конференциям, например, таким, как SQA Days, или читаешь отзывы о ConfetQA, зачастую слышишь и видишь примерно одно и то же.
- Ах, как это все просто и понятно.
- Спасибо, КЭП!
...
Но - так ли все просто и понятно? Например, сидим мы на докладе про собеседования. Слушаем докладчика - а ведь говорит то он простые и совершенно очевидные вещи. А, ерунда это все, зачем он вообще сюда пришел?
А потом к нам приходит начальник и говорит - иди проведи собеседование. Свое первое... И что? Будете спокойны аки танк и все сразу сделаете правильно? Нет. Попробуете раз, поробуете два... А потом поймете, что велосипед докладчика то был выстраданный.
Со стороны кажется, что легко. А вот самому начать - это сложно. Если с нуля. С чего начинать, за что хвататься? Сидим в итоге, копаемся в интернете, тратим кучу времени на... Простые вещи...
Так то вот. Не расстраивайте себя лишний раз! Если Вам доклад кажется очевидным, но в реальности Вы с такой проблемой еще не сталкивались - сохраните себе видео и вернитесь к нему позже. Возможно, Вы его переосмыслите
А еще хочу напомнить, что регситрация на обе конференции уже началась! Быть может, пора зарегистрироваться, а?
Я видел, как разработчики в СУБД Oracle 8i создавали процессы-демоны, читающие сообщения из программных каналов (это механизм межпроцессорного взаимодействия в СУБД). Процессы-демоны выполняли операторы SQL, содержавшиеся в прочитанных из программного канала сообщениях, и фиксировали сделанное.
...
В версиях Oracle до Oracle 8i это был приемлимый (и практически единственный) способ реализации описанной функции. Когда я рассказал разработчикам об автономных транзакциях, поддерживаемых СУБД, они очень расстроились. Автономные транзакции, реализуемые добавлением единственной строки кода, делали то же, что вся их система.
Положительным моментом оказалось то, что можно было выкинуть существенную часть кода и не поддерживать его в дальнейшем. Кроме того, система стала быстрее и проще для понимания. Но их это все равно мало радовало, - очень уж много времени было потрачено на изобретение велосипеда.
Так вот, к чему это я - пока бродишь по конференциям, например, таким, как SQA Days, или читаешь отзывы о ConfetQA, зачастую слышишь и видишь примерно одно и то же.
- Ах, как это все просто и понятно.
- Спасибо, КЭП!
...
Но - так ли все просто и понятно? Например, сидим мы на докладе про собеседования. Слушаем докладчика - а ведь говорит то он простые и совершенно очевидные вещи. А, ерунда это все, зачем он вообще сюда пришел?
А потом к нам приходит начальник и говорит - иди проведи собеседование. Свое первое... И что? Будете спокойны аки танк и все сразу сделаете правильно? Нет. Попробуете раз, поробуете два... А потом поймете, что велосипед докладчика то был выстраданный.
Со стороны кажется, что легко. А вот самому начать - это сложно. Если с нуля. С чего начинать, за что хвататься? Сидим в итоге, копаемся в интернете, тратим кучу времени на... Простые вещи...
Так то вот. Не расстраивайте себя лишний раз! Если Вам доклад кажется очевидным, но в реальности Вы с такой проблемой еще не сталкивались - сохраните себе видео и вернитесь к нему позже. Возможно, Вы его переосмыслите
А еще хочу напомнить, что регситрация на обе конференции уже началась! Быть может, пора зарегистрироваться, а?
Это называется hindsight bias и с ним очень сложно бороться. Детали тут:
ОтветитьУдалитьhttp://en.wikipedia.org/wiki/Hindsight_bias
Или тут:
http://www.forex-psychology.com/oberlehner24.html
))
ОтветитьУдалитьну вот под утренний кофий прочла сейчас отзывы о конференции SQA последней.
Два последних.
)))) ну ....
не мотивируют отзывы на прослушивание докладов.
)) на погулять по Минску -да, мотивируют!
Почему-то много про слайды-микрофоны в отзывах.
А про информационную насыщенность доклада - нету. Или я не увидела.
Так что - если есть где на просторах интернета отзывы именно об ИНФОРМАЦИИ в ДОКЛАДАХ, а не о микрофонах, обедах, душе, самолете - то с удовольствием прочту))) .
И (возможно!) схожу в Питере на конференцию.
А зачем автору отзыва мотивировать, если это не реклама?
Удалить>Так что - если есть где на просторах интернета отзывы именно об ИНФОРМАЦИИ в ДОКЛАДАХ...
УдалитьРекомендация:
Посмотреть записи. Самому определить - стоит или нет идти. Чужое мнение об информации в докладах (которое, конечно же - объективно (*СарказмЪ*)), может не оправдать ожидания. :-(
? Какие записи я могу посмотреть ДО конференции?
УдалитьА после конференции зачем смотреть? Я ценю свое время, и не хочу терять его на просмотр и прослушивание записей.
Напечатанный текст доклада я бы прочла. И времени на чтение потратила бы меньше, чем на прослушивание. И информативность проще оценить. И анализировать было бы проще. ))
А чужое мнение - ценно. Потому что это мнение специалиста, которого чем-то привлек доклад.
цитирую Вас:
Удалить"Так что - если есть где на просторах интернета отзывы именно об ИНФОРМАЦИИ в ДОКЛАДАХ, а не о микрофонах, обедах, душе, самолете - то с удовольствием прочту))) ."
Значит я не верно Вас понял. И отзывы об ИНФОРМАЦИИ в ДОКЛАДАХ необходимы до конференции.
Елена, то есть Вы хотите, чтобы люди, прослушавшие доклад, выложили потом напечатанный текст самого ценного в нем, чтобы Вам было проще анализировать? :)
УдалитьИли чтобы автор это сделал... Только зачем ему это - ведь потом выложат записи докладов.
А в отзывах кто что ищет, я, читая отзывы, видела позывы "обязательно посмотрите видео, если не были на докладе" и сама про некоторое это писала.
К тому же чужое ИМХО Вам врядли поможет, откуда людям знать, какие у Вас проблемы? Допустим, я уже 5 лет собеседую людей, пришла послушать доклад об этом и он мне ну просто ниочем, все уже знаю. А для кого-то станет откровением... Анонсы докладов публикуются. Читаете темы, читаете описание - и делаете вывод "ехать или не ехать".
И да, цена уже будет больше. И это естественно, потому что в это время уже будет понятно, за что отдаешь деньги
Это ожидаемое поведение, как и отзывы, комментарии в анкетах и т.п. :)
ОтветитьУдалитьИ не только в IT такая беда есть.
"Знание задним числом заставляет нас систематически недооценивать неожиданность научных открытий, особенно тех открытий, которые мы можем понять; тех открытий, которые нам близки, и которые мы можем постфактум уместить в свою модель мира. Регулярно читающий новости человек, разбирающийся в неврологии или физике, скорее всего тоже недооценивает неожиданность открытий в этих дисциплинах. Этот эффект несправедливо обесценивает вклад исследователей, и, что ещё хуже, не даёт тебе заметить свидетельства, которые отличаются от того, что бы ты предсказал на самом деле."
http://lesswrong.ru/w/%D0%97%D0%BD%D0%B0%D0%BD%D0%B8%D0%B5_%D0%B7%D0%B0%D0%B4%D0%BD%D0%B8%D0%BC_%D1%87%D0%B8%D1%81%D0%BB%D0%BE%D0%BC_%D0%BE%D0%B1%D0%B5%D1%81%D1%86%D0%B5%D0%BD%D0%B8%D0%B2%D0%B0%D0%B5%D1%82_%D0%BD%D0%B0%D1%83%D0%BA%D1%83