Подбор цветов

Сегодня помогал Диме подобрать цвет для выделения строки таблицы, который подходил бы к общей теме сайта. Денис увидел и попросил запостить метод и название тулов сюда, чем собственно и занимаюсь) Что я делал:
Поставил ColorZilla плагин к FF (позволяет без лишних телодвижений определить цвет в любой точке страницы). Затем пошел на сайт http://kuler.adobe.com , затем перешел сюда ввел Base Color (который я достал при помощи вышеупомянутого плагина) и по нему подобрал несколько схожих цветов. Затем выбрал один из этих цветов и прикрутил к css-классу. Просто и быстро)

1. Когда я программирую, я стараюсь думать: «Как бы мне написать это так, чтобы люди, которые будут читать мой код, восхищались тем, насколько он компактный и насколько мало он делает?» (об итеративности в программировании)

Если черная обезьяна собрала много бананов, то ей доверят собрать еще больше. Если белая обезьяна загубила много бананов, то ей доверят загубить еще больше. (о неграх и шерифах)

CLIP - быстро скопировать все из консоли в буфер обмена

Искал в пуске Clipboard Viewer - раньше была такая утилита для просмотра содержимого буфера обмена. Нашел только clip.exe и Office Clip Organizer. Решил посмотреть, что за clip.exe.

Вот что она сама о себе сообщает (clip /?)

CLIP

Description:
Redirects output of command line tools to the Windows clipboard.
This text output can then be pasted into other programs.

Parameter List:
/? Displays this help message.

Examples:
DIR | CLIP Places a copy of the current directory
listing into the Windows clipboard.

CLIP < README.TXT Places a copy of the text from readme.txt
on to the Windows clipboard.

Теперь проблема копирования всего списка файлов из папки в буфер обмена в текстовом виде решена)

DIR c:\ | CLIP

Удачи.

Тех. Люди #6. Труд и удовольствие

Тех. Люди #6

Труд и удовольствие

По-моему, подошло самое время для следующего поста. У меня в последнее время складывается впечатление, что какие-то потусторонние силы готовят меня к запуску в космос: английский, учёба вождению, перегрузки на работе, энергетические вампиры, представленные детьми, придуманный мной для себя режим (самосовершенствование вечером и пробежки утром), сон по 6 часов, постоянные стрессы из-за вождения... Наверное, точно в космос полечу. И тут самое, наверное, важное - не сорваться и сохранить себя.

Жизнь слишком коротка. Труд занимает основную часть нашей жизни. И было бы совершенно неправильно не получать ничего от того, что ты делаешь.

Получать удовольствие от труда иногда достаточно трудно. Не всегда интересные проекты, много стрессов, короткие сроки, монотонность работы, разрдражение на коллег, телефон, который мешает работать, доступ в интернет, который отвлекает и т.д.. Но надо постоянно напоминать себе, что работа – это удовольствие, а значит и твоё душевное равновесие.

Для себя я выработал набор правил, которые соблюдаю и которые помогают мне беречь себя. Ниже они перечисляются. Не все они безукоризненно исполняются, но если стремится к этому, то это будет уже пол-дела.

 

Центр

В центре всего и работы в том числе стоите вы сами. Не начальник, не проект, не успех проекта. Вы. Прежде всего вы сами. Проекты приходят и уходят, а вы остаётесь.

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

Не важно как проект закончится, в конце у вас должно остаться удовлетворение самим собой – вы сделали всё, что было в ваших силах. Вы работали честно, упорно и сделали всё, что в ваших силах.

Самое главное понимать, что в центре всего этого стоите сами вы. Не работа, а вы контролируете себя и ваше равновесие. Это ваша жизнь и несёте ответственность за неё вы сами, вы должны контролировать её, а не кто-то или что-то извне.

 

Жить на все 100

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

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

После в другой замечательной книге нашёл подтверждение этой практики. Точного названия не помню, но смысл приблизительно – жить на все 100. Т.е. чтобы ты не делал, отдаёшься этому на 100% без остатка и тебе идёт максимальный возврат в виде удовлетворения от того, что ты делаешь.

А ещё один человек описывал, как дети смотрят мультфильмы (конечно, когда их очень очень редко смотрят). Они смотрят не глазами, они смотрят этот мультфильм всем телом. Каждая клеточка от кончиков пальцев на ногах до макушки жаждет этого мультфильма и после идёт поглощение этого мультфильма всем телом. Замечательно, конечно, описал. Идея в том, что если ты что-то делаешь, то отдаёшься этому на все 100. Ты ешь – и каждая твоя клетка получает удовольствие от еды, ты едешь на машине и ловишь постоянно себя на том, что как это классно управлять автомобилем, ты идёшь и чувствуешь огромное счастье, что тебе ничего не болит (обычно такое состояние мы испытываем после того как пару дней нам, например, зуб поболел, но почему не ловить такое состояние всегда – тебе ведь ничего не болит).

От работы даже самой рутинной начинаешь получать удовольствие, если отдаёшься ей полностью и не даёшь другим вещам вмешиваться в это. За собой заметил, что если начинаю переключаться на чтение, к примеру, почты или блогов, несвязанных с работой или заполнением какого-нить бланка (опять же не по работе), то всё... можно сказать день потерян. К вечеру, не чувствую никакого удовольствия, от проведённого дня.

Уже давно завёл себе за правило - на работе только работа. Поменьше личного. Никаких блогов, видосов, самообразования – это я откладываю на нерабочее время. Даже сейчас, я разграничил себе чётко время – если прихожу до 10 часов, то никакой работы до 10, а после 10 – ничего лишнего. И это помогает.

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

Проблема телефона на работе всё ещё остаётся для меня проблемой, но всеми силами пытаюсь эту проблему разрешить. В чём проблема. Выше уже сказал, что если ты на работе, то только работа. Но что делать с теми вещами, которые нельзя просто так выкинуть из повседневной жизни. Телефон как-то особенно выбивал из колееи. Сидишь, работаешь, полностью в работе, а тут звонок – любимая, к примеру, звонит узнать как дела. Тебя прерывают, тебе нужно остановиться на полстрочке кода или на полписьме – вот тут на тебя наплывает раздражение. А ведь тебя любимая просто хочет приободрить, узнать как дела, сказать что любит и ждёт. Частично эту проблему уже решил для себя: принял как должное, что телефон тебя может останаваливать в работе и это нормально, и разговору по телефону отдаёшь себя полностью, т.е. не смотришь в экран, парралельно читая почту, или исправляя в коде ошибку, а полностью, когда только ты и разговор по телефону (лучше выхожу в коридор подальше от компа, или моник полностью выключаю (хотя иногда неподсознательно его включаю во время разговора)).

Конечно иногда стрессы с работы не дают тебе полностью отдаться семье. Но это чаще неконроллируемое чувство, с которым очень трудно справиться. Но с этим нужно бороться и искать пути как их выбрасывать из личной жизни.

 

Надеятся на других

Вот это самый трудный пункт в плане объяснить. Никогда не полагайся на других в твоей работе. Жутковато звучит, потому что нельзя не полагаться, потому как команда вокруг и один в поле не воин. Но я уже такое кол-во шишок себе в этом плане набил, что понял одно – скажем так, никогда не полагайся 100% на других, даже если человеку полностью доверяешь – у человека могут возникнуть обстоятельства, он может заболеть, он может приоритет задач себе другой выбрать, он может забыть – всякое может произойти.

Ещё раз повторю, это пришло из моего собственного личного опыта. Если можешь сам сделать или проконтролировать это – сделай лучше сам.

 

Делегируй ответственности

И в тоже время – полагайся на других (не на 100%). Один ты ничего не сможешь сделать. Помню, Юра В. в роли менеджера как-то незаметно начал работать по 12-14 часов и всё одно не всё успевал. И это не нравилось ни ему, ни мне. А кол-во задач и зон ответственности у него всё увеличивалось. А отдать тоже некому, потому как не хватит знаний и сил. И решение мы вместе с ним нашли - делегировать задачи, даже если люди ещё не готовы к таким задач. Научатся. И это сработало.

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

Ни в коем случае не говорю, что не надо быть ответственным и спихивать ответственность с себя. Ответсвенным надо быть за любое решение, что ты принял, или кусок, что ты отдал, и сделал за него ответственным другого человека. Но это скорее более высокоуровневая ответственность. Виновным, что этот кусок не сделан, будешь ты.

 

Не бойся показаться глупым

Это, наверное, многие заметили. Больше всего вопросов (даже самых простых) задают люди кто посильнее. Это, наверное, опыт. С годами начинаешь осознавать, что задавая даже самые глупые вопросы, ты не выглядишь глупым. Да и вообще забиваешь на это, что можешь показаться глупым, когда чувствуешь уверенность в себе.

Это когда молодой да зелёный, киваешь головой даже тогда, когда тебе ничего не понятно. Даже себя помню... Но ни капли не переживаю, так и должно было быть. Это нормально.

Тут правда и в другую крайность в падать не надо. Был у меня опыт, когда вместо того, чтобы что-то делать, было в основном дотошное изучение вопроса, причём процент случайности 95% случаев был менее одного процента. Тут просто не туда энергия тратилась. И на выходе мы получили ничего. Вообще, ничего - этот функционал выкинули с продакшна из-за его слабости.

 

Боязнь ошибок

Где-то уже ранее в постах мы описывали это. Не делает ошибок тот, кто ничего не делает. Поэтому самое главное не боятся сделать то, что видишь нужным.

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

Понятно, что ошибки будут. Они по статистике будут. Из 100 раз один раз обязательно не получится. Но 99 раз можно сделать и всё пройдёт, и через этот 1% иметь силы перешагнуть.

 

Отношения в команде

Проекты уходят и приходят, а люди остаются. Не мешай проектам и работе портить отношения с твоими коллегами. Построение отношений между людьми – сложная и трудоёмкая задача. А разрушить отношения и сделать себя неприятным в глазах других людей – минутное дело.

Уважение – вот что главное в отношениях. В любых отношениях между людьми. Никогда не делай ничего неуважительного, по отношению к другим. Относись к другим так, как хочешь чтобы относились к тебе. Золотые слова.

Подумай, будет ли тебе приятно, что тебя в клуб анальных девственников запишут или представят геем на весь мир. Не думаю, что это приятно. Шутки должны быть подобрее и как можно менее оскорбительными.

 

Уровень приемлимо

Всегда стоит помнить, что есть уровень – приемлимо. Опять же мысль одного человека, с которой полностью согласен (по большей части мы на своём жизненном пути не придумываем что-то новое, а собираем лучшее от других людей).

Лучшее – враг хорошего. Это уже народное.

Помню проект один. Ни одна строчка кода мимо меня не прошла. Практически всё было как мне того хотелось. Уровень качества кода был довольно высокий. Нагрузка на меня как на лида была колосальная. Это качество тянуло очень много доп. ресурсов. Не помню даже, во сколько раз мы превысили бюджет и сроки. А в конце понял одну простую истину – что достаточно было уровня хорошо, а эта разница между хорошим и лучшим могла быть доделана потом или не сделана вообще. Но овертаймов не было бы, и такого превышения бюджета. Хорошего было достаточно.

Сейчас код ревью делаю не так придирчиво как раньше. Пусть кривовато, но если это работает – пусть работает. Конечно, если это кричитическая вещь, то обязательно это к исправлению. Рефакторинг можно делать до бесконечности долго.

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

Другой человек сказал. Что профессионалом считается тот, у кого перед дедлайном ещё остаётся время, чтобы что-то улучшить.

Хотя сейчас на проекте мы делаем всё универсальным. ;)

 

Срывы

Уже видел воочию пару примеров, как люди срываются на работе, и ещё пару случаев рассказали знакомые. Или как люди в больницу надолго ложились по окончанию проекта, тоже видел.

Что тут сказать... Трудно комментировать.

Главное, костьми ложится не надо, сказал один замечательный человек. И я его полностью поддерживаю. Вы можете отдавать себя 100% в работе, но одержимым работой или проектом быть не стоит. В большинстве своём, овчинка не стоит выделки. Это всё таки выше здоровье.

 

Требование уважения

Уважать нужно не только других людей, но и требовать уважение прежде всего к себе. Я в первом посте писал о зависимости уважения других к тебе от твоего личного опыта и самоуважения к самому себе. Не надо скрывать того, что вы сдали 20 сертификатов, или поломали что-то, или курсы закончили.

Моя огромная официальная подпись (все её видели) это, скажем, первое требование к другим относительно уважения ко мне. В первую очередь это важно при работе с конечными клиентами. Не зря есть корпоративная политика по написанию писем и подписей в частности.

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

Подпись – это только один из примеров. Главное, не стесняться показать, что ты умеешь и на что способен. К тебе будет столько уважения, сколько ты сам к себе этого требуешь.

 

Качество работы

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

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

Труд программиста сам по себе созидателен. Какое удовольствие получишь ты, если построишь какашку, и какое удовольствие ты получишь, когда вчекинишь код, который никому потом не придётся исправлять, потому как ты отбросил лень и спешку, и качественно сделал своё дело.

Именно лень и спешка мешают программистам писать хороший код.

Но опять же есть у меня один пример запасе. Его уже описывал выше. Люди хотели написать очень качественный код и всё время обсуждали все-все случаи и спешку напрочь выкинули. И не получили ничего. Не надо забывать про уровень приемлимо.

А есть куча других примеров, когда человек чекинов 5 делал, а проект из сорс контрола всё не хотел собираться и работать.

Скажем так, есть не спешка – есть сроки. Сроки как раз для уровня приемлимо.

 

Вот приблизительно так... Жду комментов.

Тонкости лома каптчи или как лишить Данчу работы

Привет,

Многие, наверное, слышали о моём споре с Женей Д., что я сломаю его каптчу до конца месяца, которую он лично разработал для нашего сайта.

Признаюсь, когда спорил, даже толком в код не посмотрел, а действовал по принципу – ПОЛОМАТЬ МОЖНО ВСЁ. Я просто пошутить хотел, а Женя всё по-серьёзному решил спорить. И завязался спор на тортик до конца месяца, что я сломаю его творение. J

Сразу хочу сказать, что сама каптча написано высококлассно и защищена практически от всех известных атак по каптчам. Споры разделились относительно можно нашу каптчу поломать распознаванием или нельзя. Мнения были разные. Но в эту сторону я даже не смотрел – во-первых, знаний по распознаванию образов и нейронным сетям ещё не хватает, а во-вторых, есть хорошая пословица – "Двери крепки, да петли хлипки".

Немного о самой каптче. Это серверный хэндлер, который генеряет текст для каптчи и кладёт его в сессию и по этому тексту генеряет картинку. Страница регистрации содержит ссылку на этот хэндлер. Т.е. по загрузке страницы на клиенте идёт ещё один запрос на сервер в хэндлер для получения картинки. Пользовать заполняет форму, разгадывает каптчу и отсылает запрос на сервер. На сервере введённый текст для каптчи сравнивается с тем, что лежит в сессии, и если всё верно регистрация продолжается.

Всё стандартно. И работает отлично.

А потом глянул в код и нашёл таки 2 узких места.

Уязвимость номер 1.

Что будет, если загрузить страницу регистрации, а запрос на генерацию каптчи забанить? С каким значением будет сравнивать сервер пользовательский ввод? Вот здесь и была уязвимость. Женя сравнивал пользовательский ввод с... константой. Т.е. если в сессии ключа нет, то сравнивал с "EmptyText". Ну, дальше, все сообразили, что надо ввести пользователю, чтобы пройти регистрацию.

Почему была? Только-только похвалился Жене, что уже нашёл дыры, Женя ещё раз всё пересмотрел, переписал (даже к сессию стал ложить не сам текст, а только его хэш), и этой дыры больше не оставил. А жаль... это самый простой способ похачить.

Уязвимость номер 2.

Связана с неодноразовостью самой каптчи. Что это значит? Один раз разгдав каптчу, пользователь может зарегистрировать 1000 пользователь под одной и той же каптчей. Из сессии ведь никто не удаляет текст каптчи, оставшейся после предыдущей регистрации пользователя.

Дабы, подтвердить это, я написал небольшой экспоит для всем хорошо вам известного сайта, где наша каптча лежит.

Что скриптик делает:

1. Предоставляет красивый итерактивный интерфейс на WPF
   
   
   


2. Делает запрос на страницу регистрации на сервер, чтобы получить ASP.NET Session кук
   
3. И делает ещё один запрос на сервер в хэндлер генерации каптчи, дабы получить картинку (ессно с куком полученным на шаге 2)
   
   
   
4. Пользователь вручную разгадывает каптчу (один разок всего)
   
   
5. Скрипт посылает 10(0)(00) постов запросов на сервер использую разгаданную каптчу и сессионный кук, иммитируя настоящую страницу регистрации
   
   
6. Сервер успешно создаёт всех юзиков
   

   Даже залогиниться могу под этими аккаунтами
   

   

 

Вот, собственно, и всё. Можно сказать, что это проблема не каптчи, а кода, который каптчу юзает (к примеру, сессию после регистрации нужно полностью убивать, или явно вызывать перегенерять текст). Но... Основная цель каптчи как компоненты для регистрации пользователей - это предотвратить построение ботов для автоматической регистрации пользователей. Цель недостигнута – вышеуказанный скрипт не что иное как настоящий бот.

Поэтому эта дыра каптчи, которую надо исправлять. Как? Сами догадаетесь, как одноразовость каптчи организовать.

А ещё это значит, что скоро мы все дружно большой тортик поедим, который нам Женя Д. в салодком фальварке купит.

PS. Я на мыло лично вышлю (если кому интересно) сердцы скрипта по автоматическому созданию юзиков на нашем сайте.

 

 

 

Типы файлов и "ASP.NET пайплайн"

Как-то давно возникал вопрос проходят ли через ASP.NET запросы к файлам картинок, скриптов, css-к и тому подобным ресурсам. Сегодня нашлось время это проверить и оказалось, что под студийным веб-сервером проходят, а под IIS-м - нет. Так что ограничивать доступ к таким файлам на уровне веб-конфига не получится. Хотя если захотеть, думаю можно и под IIS-м пропустить все что хочется через ASP.NET, только вряд ли стоит это делать.

WCF, Known Types, Serialization, Dictionary

Если вам знакомо большинство слов из названия статьи то вам сюда.

Итак, проблема. Есть контракт сервиса:

1. [ServiceContract]


2. public interface IService1


3. {


4. [OperationContract]


5. string GetData(int value);


6. [OperationContract]


7. CompositeType GetDataUsingDataContract(CompositeType composite);


8. }

* This source code was highlighted with Source Code Highlighter.
Описание CompositeType ниже:

1. [DataContract]


2. public class CompositeType


3. {


4. [DataMember]


5. public string StringValue


6. {


7. get;


8. set;


9. }


10. [DataMember]


11. public Dictionary<string, object> Parameters


12. {


13. get;


14. set;


15. }


16. }

* This source code was highlighted with Source Code Highlighter.
Все довольно просто.
Создаем простой клиент для этого сервиса и пытаемся передать int[] в нашем словаре параметров CompositeType.Parametes (Dictionary):

1. Service1Client client = new Service1Client();


2. CompositeType input = new CompositeType();


3. input.Parameters= new Dictionary<string, object>();


4. input.Parameters.Add("array", new int[] { 1, 2 });


5. CompositeType output = client.GetDataUsingDataContract(input);

* This source code was highlighted with Source Code Highlighter.
И при работе получаем такое вот исключение:

There was an error while trying to serialize parameter http://tempuri.org/:composite. The InnerException message was 'Type 'System.Int32[]' with data contract name 'ArrayOfint:http://schemas.microsoft.com/2003/10/Serialization/Arrays' is not expected. Add any types not known statically to the list of known types - for example, by using the KnownTypeAttribute attribute or by adding them to the list of known types passed to DataContractSerializer.'. Please see InnerException for more details.

В интернете куча таких постов, которые до сих пор висят без ответа. Ни ServiceKnownType, ни KnowType аттрибуты не помогают. Потому что они работают для классов-наследников.

Решение этой проблемы гениально просто.
Добавляем аттрибут [KnownType(typeof(int[]))] или [ServiceKnownType(typeof(int[]))] куда нужно и в DataContract-класс добавляем поле типа System.Object.
(For english readers: solution is pretty smart. Just add to DataContract-class DataMember field of type System.Object. Then use KnownType or ServiceKnownType attributes )

1. [DataContract]


2. [KnownType(typeof(int[]))]


3. public class CompositeType


4. {


5. [DataMember]


6. public object UsedForKnownTypeSerializationObject;


7. [DataMember]


8. public string StringValue


9. {


10. get;


11. set;


12. }


13. [DataMember]


14. public Dictionary<string, object> Parameters


15. {


16. get;


17. set;


18. }


19. }

* This source code was highlighted with Source Code Highlighter.

Похожий вопрос тута
All about known types
Data Contract Known Types

Command Shell tricks

То же похвалюсь. Пару дней назад узнал ещё один трик с работой из командных файлов.

Теперь как минимум 2 трика знаю:
1) Получить текущую директорию
echo %cd%




2) Установить в бат-файле текущую директорию как текущую директорию где сам файл находится
Пример,




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



Здесь на помощь придёт вот этот трик cd /d %~dp0. Он устанавливает текущую директории, где сам бат-файл лежит.






Пишите в комментах ещё трики, если у вас в запасе есть, и пусть это останется в истории. и не надо будет по закоулкам лазить, чтобы поднять старые знания, как это иногда приходится делать.

Using SQL for Active Directory

Мне аж самому понравилось и чтобы не забыть, когда в след. раз понадобится пощу сюда.



sp_addlinkedserver 'ADSI', 'Active Directory Services 2.5', 'ADSDSOObject', 'adsdatasource' 
go

SELECT REPLACE(userPrincipalName, '@sam-solutions.net', '') as l, 
telephoneNumber, Name FROM OPENQUERY( ADSI, 'SELECT displayName, 
sn, name, cn, telephoneNumber, userPrincipalName FROM 
''LDAP://DC=sam-solutions,DC=net'' WHERE objectCategory 
= ''Person'' AND objectClass = ''User'' AND memberOf = 
''CN=tbw,OU=groups,OU=dept2,OU=SamSol,OU=Belcaf,DC=sam-solutions,DC=net'' ') 
order by l

Список высокорекомендуемой литературы для программиста

Привет,

Может некоторые заметили, в письме, которое отсылаю для новеньких на проекте от том, что поставить для работы, включаю 2 книги как Highly Recommended для чтения:

1. Рихтера (CLR via C#)
   
2. Дино эспозито (ASP.NET)
   

У меня лежит запрос на "что ещё можно почитать из recommended". Оно и правда – среди книг шлака очень много. Даже сейчас читаю книгу, что Саша С. Подогнал по WCF – руки поотрывал бы автору – очень слабо.

Я прочитал довольно много книг - ~60% из них не рекомендовал бы ни в коем разе – потеря времени. Но есть очень хорошие авторы. Из всего набора сегодня выделил 10 лучших книг, которые читал и которые высоко рекомендую.

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

 

1. Security (книга a и b ну просто must – огненные штуки)
   
   1. Writing Secure Code
      

      Коммент: читал в бумажном виде, в своей эл. Библиотеке не нашёл
      

      
       

   2. Hacking the Code by Mark M. Burnett and James C. Foster –
      

      Коммент: есть в эл. Виде в моей библиотеке
      

      (Hacking the Code - ASP.NET Web Application Security Cookbook (2004) .chm)
      

      НЕ ЧИТАЙТЕ РУССКИЙ АНАЛОГ В ИЗБЕЖАНИИ ПОТЕРИ МОЗГА
      

   
    

   
    

2. ООП
   
   1. Объектно-ориентированный анализ и проектирование Гради Буч
      

      Коммент: Книга на русском, есть в эл. Виде. Буч тяжёл для восприятия, но пробивает насквозь. Классика.
      

   
    

3. .NET
   
   1. CLR via C#
      

      Коммент: no comment – must
      

      
       

   2. .NET Gotchas By Venkat Subramaniam
      

      Коммент: раскрываются тонкости языков и платформы (OReilly.dot.NET.Gotchas.May.2005.chm)
      

      
       

   3. Essential .NET - Volume 1 The Common Language Runtime.chm
      

      Коммент: книга про .NET 1.1, но есть часть того, чего в рихтере нет. Не знаю, есть ли продолжение для .Net 2.0 – сам почитал бы (OReilly.dot.NET.Gotchas.May.2005.chm)
      

 

1. Aрхитектура
   
   1. Patterns of Enterprise Application Architecture by Martin Fowler - Коммент: Есть эл. вариант (Addison Wesley - Patterns of Enterprise Application Architecture.chm). Отличная книга как первая для захода в архитектуры
      

      
       

      
       

   2. Шаблоны проектирования для Java
      

      Коммент: Читал бум. Версию. не нашёл в электронной своей библиотеке пока той, которую читал. Буду искать.
      

      
       

   3. Книга про построение кластеров
      

      Коммент: пока не нашёл. Буду искать.
      

   
    

2. Misc
   
   1. Refactoring. Improving the Design of Existing Code
      

      Коммент: no comment. Замечательная книга. (Refactoring. Improving the Design of Existing Code.pdf)