Вариант построения системы управления задачами небольшой команды разработки. Без вовлечения руководства, на возможностях имеющегося трекера.
Полезные борды и другие приёмы из личной практики.
Joel Spolsky: Круг почета для Ask Patents
7 min
Translation
В наши дни множество людей жалуется на паршивые патенты на программное обеспечение (ПО). А а говорю: «Прекратите жаловаться и начните уничтожать их». У меня заняло приблизительно 15 минут времени, чтобы предотвратить подтверждение одного дрянного патента Microsoft. Есть 15 минут? Можете тоже сделать это.
Джоэл Спольски — блогер, предприниматель, программист
18 min
Джоэл Спольски, пожалуй, один из самых известных айтишных блогеров. Переводов статей из его блога Joel on Software на Хабре было множество, и наверняка кто-то из вас читал его книги «Джоэл о программировании», «Лучшие примеры разработки ПО» и «Руководство по UI дизайну для программистов».
Может, вы что-то слышали про дырявые абстракции, тест Джоэла и алгоритм маляра. А если нет, то сайт Stack Overflow уж точно знаете — так вот, это дело рук Джоэла Спольски, так же, как и канбан-инструмент Trello и… отчасти MS Excel. Да, Джоэл поработал и над ним. В общем, настоящий человек-оркестр, который поучаствовал во многих проектах, и останавливаться не собирается.
IT-сообщество должно знать своих героев, поэтому предлагаем вам окунуться в лихие 2000-е и почитать захватывающую биографию мистера Спольски. А еще в 2020 году Джоэл выступал на нашей конференции JPoint и поведал нам кое-что интересное, о чем расскажем в посте.
Смерть OS/2
3 min
В обсуждении Windows 3.1 на прошлой неделе danSamara упомянул:
Как же так вышло, что убогая и неказистая Windows задушила мощную и совершенную OS/2?
Рассказывают разработчики:
Рэймонд Чен: «убойной прогой» для Windows 1.0 — той, ради которой люди готовы были купить новую ОС, — был Adobe PageMaker. Потом появился ещё и Excel.
Ларри Остерман: на самом деле, Pagemaker и Excel были «убойными прогами» для MacIntosh; уже впоследствии их выпустили и для Windows.
Насколько я помню, под Windows вообще не было «убойных прог». Windows 1.0 и 1.1 продавались скромными тиражами по паре тысяч копий в месяц. Windows 386 (версия 2.0) продавалась лучше, потому что позволяла запускать одновременно несколько DOS-приложений. Не любые приложения можно было запускать одновременно; фактически, едва ли можно было запустить что-то более сложное, чем несколько копий GWBasic.
Всё поменялось, когда вышла Windows 3.0.
Ваша сложная и многогранная система работала у меня в виртуальной машине из под OS/2, которая уже тогда была по настоящему 32-разрядной и многозадачной, а ваша суровая многогранная правда выглядела убого и неказисто.
Как же так вышло, что убогая и неказистая Windows задушила мощную и совершенную OS/2?
Рассказывают разработчики:
Рэймонд Чен: «убойной прогой» для Windows 1.0 — той, ради которой люди готовы были купить новую ОС, — был Adobe PageMaker. Потом появился ещё и Excel.
Ларри Остерман: на самом деле, Pagemaker и Excel были «убойными прогами» для MacIntosh; уже впоследствии их выпустили и для Windows.
Насколько я помню, под Windows вообще не было «убойных прог». Windows 1.0 и 1.1 продавались скромными тиражами по паре тысяч копий в месяц. Windows 386 (версия 2.0) продавалась лучше, потому что позволяла запускать одновременно несколько DOS-приложений. Не любые приложения можно было запускать одновременно; фактически, едва ли можно было запустить что-то более сложное, чем несколько копий GWBasic.
Всё поменялось, когда вышла Windows 3.0.
Hg Init: Часть 1. Переобучение для пользователей Subversion
9 min
Translation
Hg Init: Учебное пособие по Mercurial.
Mercurial — это современная распределенная система контроля версий с открытым кодом. Эта система — заманчивая замена для более ранних систем вроде Subversion. В этом простом учебном пособии в шести частях Джоэль Спольски (Joel Spolsky) рассказывает о ключевых принципах Mercurial.Если вы использовали Subversion, то Mercurial будет непонятным. Эта часть рассказывает о главных отличиях при работе с Mercurial. Если вы никогда не использовали Subversion, то можете просто пропустить эту часть.
Часть 1. Переобучение для пользователей Subversion
В каком же я был смятении, когда программисты в моей компании решили сменить Subversion на Mercurial!
Для начала, я начал приводить всевозможные тупые причины, по которым нам не надо ничего менять. «Мы должны хранить репозиторий на центральном сервере, так безопаснее», — сказал я. Знаете что? Я был неправ. При работе с Mercurial у каждого разработчика на жестком диске хранится полная копия репозитория. Это, на самом деле, безопаснее. В любом случае, почти в каждой команде, использующей Mercurial, центральный репозиторий тоже существует. И вы можете делать резервное копирование этого репозитория со всей необходимой одержимостью. А еще можете устроить трехступенчатую защиту с Сайлонами, Штурмовиками и прелестными лабрадудлами или что там требует ваш IT-отдел.Hg Init: Часть 2. Основы Mercurial
7 min
Translation
Это вторая часть из серии Hg Init: Учебное пособие по Mercurial от Джоэля Спольски (Joel Spolsky). Возможно, вы захотите прочитать и первую часть «Переобучение для пользователей Subversion».Даже если вы работаете в одиночку, то вам стоит использовать Mercurial. Так вы сможете получить все прелести контроля версий. Эта часть покажет насколько просто добавить каталог в Mercurial, чтобы с легкостью отслеживать предыдущие версии.
Часть 2. Основы Mercurial
Mercurial — это система контроля версий. Разработчики используют ее для администрирования исходного кода. У нее два основных назначения:- Она хранит все предыдущие версии каждого файла
- Она может объединить разные версии вашего кода, то есть сотрудники могут независимо работать над кодом и затем объединять свои изменения
Hg Init: Часть 3. Привыкаем работать в команде
7 min
Translation
Это третья часть из серии Hg Init: Учебное пособие по Mercurial от Джоэля Спольски (Joel Spolsky). Предыдущие части:Одно из преимуществ использования Mercurial — возможность работать командой над одним кодом. Mercurial позволяет каждому работать независимо и помогает объединять сделанные изменения.
Часть 3. Привыкаем работать в команде
При командной работе с Mercurial общепринято настраивать центральный репозиторий в дополнение к личным репозиториям, расположенным на компьютерах членов команды. Центральный репозиторий можно рассматривать как своего рода блошиный рынок, то есть, как место где встречаются и обмениваются сделанным.
Hg Init: Часть 4. Исправляем ошибки
4 min
Translation
Это четвертая часть из серии Hg Init: Учебное пособие по Mercurial от Джоэля Спольски (Joel Spolsky). Предыдущие части:Одно из главных преимуществ Mercurial состоит в том, что вы можете использовать личные клоны репозитория для экспериментов и разработки новых возможностей. Если что-то пошло не так, можно все исправить за мгновение.
Часть 4. Исправляем ошибки
Mercurial позволяет свободно экспериментировать. Представьте, что во время работы вы что-то не то сделали в редакторе, и случилось нечто ужасное:
Hg Init: Часть 5. Процесс слияния
4 min
Translation
Это пятая часть из серии Hg Init: Учебное пособие по Mercurial от Джоэля Спольски (Joel Spolsky). Предыдущие части:- «Переобучение для пользователей Subversion»
- «Основы Mercurial»
- «Привыкаем работать в команде»
- «Исправляем ошибки»
Иногда при слияниях возникают конфликты. Обычно их легко разрешить. В любом случае их надо разрешить, или у вас будет несколько «голов». А кому это нужно?
Часть 5. Процесс слияния
Обеспечение слаженной работы нескольких людей над одним и тем же кодом — это важная функция системы контроля версий.
Представьте что и Роза, и я хотим внести изменения в рецепт гуакамоле. Роза работает над качеством авокадо. Перед тем как начать, она обновляет свой рабочий каталог, вытягивая свежие изменения из центрального репозитория.
Hg Init: Часть 6. Архитектура репозиториев
5 min
Translation
Это шестая, заключительная часть из серии Hg Init: Учебное пособие по Mercurial от Джоэля Спольски (Joel Spolsky). Предыдущие части:- «Переобучение для пользователей Subversion»
- «Основы Mercurial»
- «Привыкаем работать в команде»
- «Исправляем ошибки»
- «Процесс слияния»
Mercurial позволяет очень гибко настроить репозитории. Плюс, так как слияния работают отлично и вы можете на них полагаться, можно иметь особые служебные репозитории в соответствии с требованиями процесса разработки в вашей команде.
Часть 6. Архитектура репозиториев
Наш рецепт становится все лучше:
Как стать героем (Яков Сироткин на ADD-2010)
15 min
Tutorial
Яков Сироткин, известный блогер и опытный разработчик любит раскрывать глаза молодых программистов на порой нелицеприятные стороны работодателей, объясняя при этом природу этих фактов.
Проблемы о которых не любят говорить на интервью, но с которыми приходится сталкиваться.
Проблемы о которых не любят говорить на интервью, но с которыми приходится сталкиваться.
- Как успешно разрабатывать программное обеспечение вопреки трудностям?
- Понравится ли это начальству?
- Что за это будет?
- Как жить дальше?
Семь шагов к замечательному клиентскому сервису
11 min
Translation
Сегодня я хочу познакомить вас с замечательной, на мой взгляд, статьей. Конечно же о сервисе :).Ее ценность не только в легком стиле или интересных практических примерах. Дело в том, что ее написал владелец бизнеса по разработке ПО, что особенно приятно. Автор статьи — Джоэль Спольски (Joel Spolsky) — основатель и владелец небольшой софтверной компании из Нью-Йорка, Fog Creek Software. По отзывам знающих людей, он — хороший специалист. По моему мнению, он еще и неплохо пишет, в чем вы можете убедиться, посетив его блог Joel on Software.А самое главное, что он ценит качественное обслуживание. Что подтверждает нижеследующая статья. Читаем. Браво, Джоэль! Полезность — 5. P.S. — для любителей оригинальных текстов — пожалуйста — Seven steps to remarkable customer service.
The Joel on Software Translation Project
1 min
Translation
Джо (Joel Spolsky) про ПО в переводе на русский — перевод блогов известного программиста
Новый Офис Fog Creek
3 min
Translation
Помните Бионический офис? Fog Creek переехала туда в 2003 году. Спустя пару лет мы переросли его, а потому расширились и заняли весь этаж. К тому времени, когда срок аренды в 2008 году истек, в офисе предназначенном для 18 человек работало 25, и мы понимали, что нужно переезжать. Кроме этого грязноватый Мидтаун, превосходный для стартапов, спустя пять лет начал раздражать. Теперь у нас было чуть больше денег, а потому мы начали искать место с площадью в два раза больше за цену, выше старой в четыре раза.
Joel Spolsky: Дипломные проекты и тайм-менеджмент
4 min
Интереса ради перевёл последнюю статью Джоела Спольски. Сразу предупреждаю, что некоторым перевод местами может показаться достаточно вольным — это сделано сознательно в угоду удобочитаемости по-русски.
Я так же позволил себе добавить в статью ссылок на переводы и описания тех слов и терминов, которые, как мне показалось, будут непонятны большинству русскоговорящих людей, а так же относительно которых я сильно сомневаюсь в адекватности собственного перевода.
Удивительно, как это легко — получить айтишную специальность в топовом университете даже не изучив основных инструментов разработчика, ни разу не поработав в команде, и ни разу не пройдя курс, за который ты не получишь минимальную оценку автоматом просто за участие.
Я так же позволил себе добавить в статью ссылок на переводы и описания тех слов и терминов, которые, как мне показалось, будут непонятны большинству русскоговорящих людей, а так же относительно которых я сильно сомневаюсь в адекватности собственного перевода.
Дипломные проекты и тайм-менеджмент
Удивительно, как это легко — получить айтишную специальность в топовом университете даже не изучив основных инструментов разработчика, ни разу не поработав в команде, и ни разу не пройдя курс, за который ты не получишь минимальную оценку автоматом просто за участие.
Joel Spolsky: Маркетологи vs. Разработчики
2 min
Translation
Перевод очередной статьи Джоела Спольски.
На ранней стадии технологического стартапа, вы склонны к тому, чтобы иметь в своем штате много разработчиков и вам кажется, что разработчиков всегда мало. Если вы нанимаете продажников и маркетологов слишком рано, тогда они оказываются не вовлечены в бурную деятельность компании, и вы начинаете думать, что продажи и маркетинг это просто потеря времени.
Маркетологи vs. Разработчики
На ранней стадии технологического стартапа, вы склонны к тому, чтобы иметь в своем штате много разработчиков и вам кажется, что разработчиков всегда мало. Если вы нанимаете продажников и маркетологов слишком рано, тогда они оказываются не вовлечены в бурную деятельность компании, и вы начинаете думать, что продажи и маркетинг это просто потеря времени.
Причина недопонимания между нами и неверного использования технологий. По мотивам статьи «Пять миров» (ПО)
4 min
Почти никогда во всей литературе, посвящённой программированию и разработке программного обеспечения, не упоминается нечто важное, из-за чего мы иногда недопонимаем друг друга... Joel Spolsky
Статья Джоэла о Пяти мирах (программного обеспечения) вышла в 2002 году. За прошедшие 14 лет успели образоваться новые миры: Мобильные приложения и Облака, — но соль статьи осталась неизменной.
Одна и та же технология в разных условиях будет давать разную эффективность.
Когда мы обсуждаем опыт применения какой-то технологии, мы часто не обращаем внимания на контекст её применения из-за этого возникает недопонимание, неверное толкование и применение технологий.
Представьте, мы на Земле, наш друг Марк на Марсе. У нас стоит одна и та же цель, вырастить в своём Мире урожай картошки. Технологию будем использовать одинаковую «посадка в грунт», а результаты получим разные так как влияние факторов/переменных разное для каждого из Миров. Это кажется очевидным, но факты из жизни говорят об обратном.
Это Марк
Как я устроился на работу в Stack Exchange
6 min
Translation
От переводчика
Перед вами перевод публикации из блога Haney Codes .NET. Автор блога David Haney работает на позиции Engineering Manager в Stack Overflow. Пару лет назад я уже перевел одну статью его авторства: Неразбериха с названиями должностей.
Около месяца назад я обнаружил себя разговаривающим по видеосвязи с Joel Spolsky (автор известного блога «Joel on Software», со-основатель Stack Overflow — прим. перев.). Даже сейчас кажется абсурдным писать подобное. Долгое время, на протяжении всей своей карьеры, я регулярно читал Joel Spolsky, и во многом сходился с ним во взглядах на разработку. И вдруг общаюсь лицом к лицу.
Добиться этого разговора было далеко не просто. Процесс занял несколько недель, и, честно говоря, было затруднительно найти время на прохождение стольких интервью. Скольких, спросите вы?
Джоэль Спольски перестает писать блог Joel on Software
1 min
Джоэль Спольски в собственной колонке журнала Inc. объявил, что не собирается впредь уделять большое внимание своему блогу joelonsoftware.com: «Итак, превратившись в знаменитость интернета в узком, обособленном мире программирования, я решил, что мне пора отойти от блогерства. Семнадцатого марта 2010 года, в десятилетний юбилей блога „Джоэль о програмном обеспечении“, я размещу последний большой пост. Данная заметка — последняя для журнала Inc. Кроме того, я не намерен серьезно заниматься подкастами и публичными выступлениями. Твитер? „Отстой, черт, чтоб его, рация; простите, всего в 140 символах я не могу рассказать, в чем дело“».
Спольски не устраивает, что продукция его фирмы Fog Creek хорошо известна «5—10 % программистов, которые читают блоги о программировании», но «почти не известна всем остальным», при том что многие фирмы «заполучили клиентов и прекрасно растут без траты кучи времени в ранние годы на создание клевого блога». Сайт, книги, лекции, видеокурсы — это примерно треть рабочего времени Спольски.
Спольски не устраивает, что продукция его фирмы Fog Creek хорошо известна «5—10 % программистов, которые читают блоги о программировании», но «почти не известна всем остальным», при том что многие фирмы «заполучили клиентов и прекрасно растут без траты кучи времени в ранние годы на создание клевого блога». Сайт, книги, лекции, видеокурсы — это примерно треть рабочего времени Спольски.
Костыльный программист
5 min
Автор: Джоэль Спольски. Оригинал.
Статья посвящена оверинженирингу и тем, кто предпочитает старые костыльные решения лишь потому, что они очень просты. Перевод под катом.
Статья посвящена оверинженирингу и тем, кто предпочитает старые костыльные решения лишь потому, что они очень просты. Перевод под катом.