SCoon the Crazy

Прочитал на Lambda the Ultimate, что The MIT is going to change its curriculum structure that was famous for teaching Scheme in introductory courses [...] The difference is that programming will be done in Python and not Scheme. Как страшно жить. Вот уж от MIT я этого не ожидал. И уж совсем дико для меня то, что инициатор -- Harold Abelson. Или это я с перепугу буквы читаю не в ту сторону?

Все ж таки вера в то, что где-то кого-то учат правильно, определенно помогала жить. С другой стороны, тот факт, что Scheme хотят менять не на Visual Basic, в какой-то степени радует. Как говаривал Друпи, "я счастлив, ура"...

Добрый человек Joel Spolsky опубликовал статью "Set Your Priorities". Собственно, ничего выдающегося в ней нет: половина статьи будет вызывать дежа вю у тех, кому знаком термин "creative procrastination", половина -- у тех, кто занимался планированием в экстремальном программировании.
( Read more... )

Аннотирование кода оказывает слишком сильное влияние на неподготовленные умы. Пожалуй, наиболее сильный вклад в бездумное распространение этой концепции внес XDoclet.
( Read more... )

Читая добрую книжку "Совершенный код", наткнулся на утверждение, согласно которому при использовании цикла for (в C-подобных языках) надлежит весь код, отвечающий за перебор элементов, выносить из тела цикла в его заголовок. А при невозможности -- использовать while.

По здравому размышлению я склонен согласиться с автором. Правда, меня печалит тот факт, что придется расставаться с любимым шаблоном обхода коллекций в Java:
( Read more... )

Вы читаете этот текст на свой страх и риск. Автор не несет ответственности на моральный или физический ущерб, который вы можете понести в результате знакомства с этим текстом.

Мы, определенно, делаем что-то не так. Ярче всего это проявляется в отсутствии гарантий. Случалось видеть дизайнерскую студию, которая обещает вернуть деньги, если в течении года клиент заявит, что сайт не оправдал его ожиданий? Без всяких оговорок. Я такого не встречал. То же касается разработки ПО, проектирования информационной архитектуры и разного рода консалтинговой деятельности.

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

Выходит -- не умеем. Что-то делаем не так. В догонку -- добрая статья "Think Guarantees":

Seven Tips for a Great Guarantee

• Make the guarantee simple and unconditional. Drop the excuses, fine print, and legalese.
  
• Be sure your entire organization embraces the operating philosophy dictated by the use of guarantees.
  
• Know your clients well enough to judge when a guarantee is helpful and when it isn't.
  
• A guarantee should be a two-way street, so include some upside if you exceed performance expectations: ask for "success" fees.
  
• Keep the discussion of the guarantee alive during the project. Monitor performance carefully to avoid surprises.
  
• Specify which client individuals are authorized to "call in" the guarantee, and make it as few people as possible.
  
• Respond quickly if a client requests that you make good on your guarantee.