Что такое маркерная доска и с чем ее есть, наверное, в курсе уже все. И этот пост — о варианте самодельной доски. Сделать такую штуку в нашем офисе меня сподвиг офис Яндекса, с их стенами, обклеенными пленкой, по которой можно писать маркером. Не прошло и месяца, как я решил

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

Быстро! Ответьте на следующий вопрос:

Как вы оцениваете свой уровень как программиста (ниже среднего, средний, выше среднего)?

Согласно психологическим опросам среди разных групп, около 90% программистов отвечают «Выше среднего».

Очевидно, это не может быть правдой.

Пару недель назад все начали писать о предстоящей майкрософтовской конференции PDC (Professional Developers Conference). В частности, Дуг Рейли написал пост «Кто управляет вашей карьерой?». Многие прочитали и сослались на пост, а некоторые (например, Сэм Джентайл или Роберт Херлбат) даже развили идею в ответных постах.

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

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

Это двадцать шестая публикация в серии публикаций о VS 2010 и .NET 4.

Сегодняшняя публикация рассматривает некоторые полезные советы по отладке которые вы можете применять в Visual Studio. Мой друг Скот Кэйт (Scott Cate) (который опубликовал в блоге дюжину великолепных советов и трюков по VS) недавно обратил мое внимание на несколько хороших советов о которых не знает много разработчиков использующих Visual Studio (даже при том, что многие из них работают с ней уже давно с более ранних версий).

При разработке баз данных зачастую требуется обеспечить поддержку версионности и хранения истории объектов. Например, у работника может изменяться должность, у должности в свою очередь может меняться оклад — в многомерном моделировании это называется Slowly changing dimensions(далее SCD) — редко изменяющиеся измерения, то есть измерения, не ключевые атрибуты которых имеют тенденцию со временем изменяться. Всего существует 6 основных типов(методов) SCD, которые определяют как история изменений может быть отражена в модели.

В современном бизнесе принято полагаться на многозадачность, и оценка сотрудника как специалиста зависит от его способности выполнять несколько задач одновременно. IT-специалисты постоянно работают в нескольких проектах сразу. Всегда ли так было? Действительно ли многозадачность необходима? Какую реальную пользу она приносит? И есть ли ей альтернативы?

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

Другая точка зрения

Когда мы говорим об опыте, полученном при работе в рамках Agile или Scrum, то всегда камнем преткновения становится идея о том, что команда работает гораздо лучше и эффективнее, если у нее постоянный состав и ее члены не заняты в других командах. В этом нет ничего нового. У нас есть многолетний опыт создания групп специалистов для решения особо трудных проблем, особенно во времена кризиса. И в то же время наши организации пришли к модели, где мультиспециалисты заняты одновременно во множестве проектов. Фактически, это единственно решение, позволяющее справляться со множеством вещей сразу. Считается, что это наиболее эффективный способ использовать «ограниченные ресурсы», то есть когда у вас мало специалистов, но все они широкого профиля.

Программистов часто обвиняют в том, что они делают свою работу неряшливо. В природе существует бесчисленное количество программ, которые падают, зависают или неожиданно пишут на экране «Превед медвед» миллион раз.

Предисловие

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

Так вот, чтобы минимизировать эти затраты, давайте «создадим» хорошего, а возможно и идеального начинающего программиста, с высоким потенциалом и светлыми горизонтами.

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

1. Будьте самостоятельными

Если у вас есть какой-то вопрос, и вы не знаете как с ним поступить, то вначале постарайтесь исследовать его самостоятельно. Не ждите постоянной помощи от коллег — у них и без вас работы хватает. Используйте всю мощь поисковых систем, специализированных ресурсов (например, stackoverflow), профессиональных блогов, форумов разработчиков, и конечно же хабра. Большинство типичных «граблей» можно обойти различными эффективными вариантами, а для решения базовых задач есть дюжины готовых решений. Просто пойдите и возьмите.

Чтобы понять рекурсию, сначала надо понять рекурсию. Возможно, поэтому рекурсивные запросы применяют так редко. Наверняка вы представляете что такое SQL-запрос, я расскажу, чем рекурсивные запросы отличаются от обычных. Тема получилась объемная, приготовьтесь к долгому чтению. В основном речь пойдет об Oracle, но упоминаются и другие СУБД.

Productivity Power Tools это набор расширений для Visual Studio Professional (и выше), которые улучшают производительность разработчиков. В новой версии расширения были добавленные такие вещи:

• Настройки расширений
• Solution Navigator
• Quick Access
• Обновление и исправление ошибок «Searchable Add Reference», «Document Tab Well» и других расширений.

Много картинок

Здравствуйте, дорогие хабравчане. Так вышло, что около полугода назад у меня получилось устроиться на работу в Швейцарии, в швейцарскую федеральную политехническую школу (EPFL) в Лозанне. К текущему моменту накопилось множество различных впечатлений, о которых я и хочу рассказать.

Роберто Иерусалимши рассказывает, как эффективно соединять немодифицируемые строки.
Несмотря на то, что код написан на Lua, алгоритм подойдёт и для других языков, в которых строки нельзя изменять.

Хороший код

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

Основное правило

Я считаю, что читаемым является код, в который можно не вчитываться.
То есть, пары-тройки строк дожно быть достаточно, чтобы сказать, что делает класс или метод. Ещё пары-тройки — чтобы примерно сказать, как он это делает.

Прочие замечания

Я заметил, что есть ещё несколько довольно общих правил, которые делают код симпатичнее.

Все знают этого «дядю» по изображению на стодолларовой купюре. Почти все знают фразу «Время — деньги», которую однажды Бен Франклин произнес. Есть много фактов из его интересной и удивительно жизни. Большинство людей не знают, что Франклин таки не был президентом США, хотя и очень активно участвовал в написании Конституции Америки. Много всяких слухов есть о масонстве, мировом порядке и так далее. Больше информации о нем можно прочесть в статье Википедии

Я бы хотел сегодня привести очень интересный отрывок из его дневника. Сегодня модно писать о том, как многое успевать, как быть эффективным, ка организовать бизнес и т.д. и т.п. К сожалению, как заметил Стивен Кови в своей книге «7 навыков высокоэффективных людей» (сам бы в жизни не читал по причине такого названия, но друг очень рекомендовал, прочитал книгу, очень доволен) сегодняшняя литература об управлении и личной эффективности сводиться к простому выписыванию рецептов решения стандартных проблем. Что-то типа аспирина на все случаи жизни. Редко встретишь книгу или статью затрагивающую глубинные мотивы, принципы внутренней жизни и целостности человека. Но сейчас не об этом… Хочу поделиться отрывком из дневника Франклина. Этот человек много достиг, поднялся с низов общества не имея официального образования, уверен, что много можно почерпнуть из его жизни.

Скажу сразу — «Америку не открываю», так же как не «изобретаю велосипед». Статья базируется на модели ситуационного лидерства Херси-Бланчарда. Сама модель в значительной степени изменена в применении к управлению именно ИТ-командами в нашей стране и подкреплена практическим опытом управления командами в Майкрософт Рус и в собственном бизнесе.

Выбирая между «академическим» и «популярным» стилями изложения выбрал «академический». Все таки разговор о серьезных вещах. Так что если эта тема Вам прямо сейчас не супер-актуальна — смотрите диаграммы, их достаточно для понимания идеи. Остальное — для достаточно узкой аудитории.

Раз за разом я вижу отблески самого себя в «молодых» программистах. Они сражаются с теми же концепциями, что и я когда-то, попадают в те же ментальные ловушки и, в общем-то, делают те же ошибки. Написав пост 4 wrong ways, я задумался, насколько распространены эти ошибки, и можем ли мы их категоризировать. Я попадался в каждую из этих ловушек хотя бы раз, в некоторые по нескольку и видел те же ошибки у других.

Я имею довольно небольшой опыт работы в сфере разработки программного обеспечения (всего 6 лет), но я уже накопил ряд полезных и правильных практик (по моему скромному мнению), которые можно использовать при создании программного обеспечения.

В основном описаны моменты которые касаются поддержки процесса разработки программного обеспечения, не затрагиваются темы планирования хода выполнения работ. Также не затронут процесс программирования и полезные плюшки для него (например расслоение системы на уровни, использование шаблонов проектирования). Но все ниже приведенное было и остается полезным для меня лично, и я буду рад если и вам на что нибудь сгодится :)

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

Стадия первая. Рождение

«Я программист. Я олимпиадник. Я знаю что такое «о»-маленькое. Я знаю, что такое «О»-большое. Я понимаю, чем отличается «эн-квадрат» от «эн-факториала» и почему они оба стыдливо прячутся при виде «эн-логарифм-эн». Сейчас я приду на проект и перепишу эту тормозную кашу из кода так, что она будет работать в много раз быстрее! Смотрите, я знаю алгоритм Кнута-Морриса-Пратта! А здесь можно сэкономить одно сравнение строчек на равность! А если эту рекурсию развернуть в цикл, то за счет экономии вызовов методов и выделения памяти в стэке… Что, программа тормозит? Сейчас я посмотрю код… Вот! Смотрите, здесь вместо двух вложенных циклов можно написать один и использовать бинарный поиск вместо внутреннего!»

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

Предлагаю вниманию читателей перевод статьи "Programming Sucks! Or At Least, It Ought To", опубликованной в «The Daily WTF». Публикация рассказывает о том, как избыток профессионализма на практике мешает эффективности и предназначена скорее для опытных разработчиков, нежели для новичков.