Мистер Томпкинс — человек уже довольно приличного возраста. Первое знакомство с ним состоялось в далеком 1938 году, когда физик и одессит Георгий Антонович Гамов опубликовал в Британском журнале Discovery серию рассказов о человеке, который в своих снах попадал в альтернативные миры, где значения физических констант радикально отличаются от значений оных в реальном мире, что приводит к совершенно неожиданным результатам. Так Гамов популярно объяснял концепции современной физики неискушенному читателю. Незадачиливым же соней был тот самый Мистер Томпкинс.

Практически 60 лет спустя Том ДеМарко решил поделиться свой безграничной мудростью и в столь же популярной форме преподнести идеи из Peopleware, написанной в соавторстве с Тимоти Листером. Итогом стал "Роман об управлении проектами", в котором наш старый знакомый Мистер Томпкинс похищается сексапильной брюнеткой Лаксой Хулигэн и увозится в загадочную страну Моровию, где ему представляется возможность провести настоящий эксперимент по управлению проектами разработки программного обеспечения…

В конце каждой главы Мистер Томпкинс подводит итоги и записывает свои мысли, которые, по сути, являются аксиомами и постулатами управления проектами по ДеМарко и Листеру. Разумеется, лучше будет прочесть всю книгу в целом — иначе не понять, как эти принципы применяются в «реальной» жизни. Но если времени нет (или же просто хочется освежить память), то вашему вниманию предагается…

Assert — это специальная конструкция, позволяющая проверять предположения о значениях произвольных данных в произвольном месте программы. Эта конструкция может автоматически сигнализировать при обнаружении некорректных данных, что обычно приводит к аварийному завершению программы с указанием места обнаружения некорректных данных. Странная, на первый взгляд, конструкция — может завалить программу в самый неподходящий момент. Какой же в ней смысл?

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

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

1. Вы не будете тратить время на оценки

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

Нашей компании уже 6 лет. Она была основана на принципах agile и росла на них. Мы использовали Extreme Programming с самого первого дня, добавили немного Scrum позже и в конце концов переключились на Kanban. Хочется поделиться бесценным опытом и рассказать об изменениях нашего процесса разработки за последние 4 года.

Ознакомившись с постами, в которых хабрапользователи описывают процессы внедрения и реализации гибких методологий в производство, решил поделиться собственным опытом разработки по методологии Kanban в небольшой продуктовой команде.

К моменту, когда у нас возникло желание попробовать новую систему организации процесса, мы были сработанной командой, ведущей успешную Scrum разработку.

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

Содержание курса

• Статья 1: алгоритм Брезенхэма
• Статья 2: растеризация треугольника + отсечение задних граней
• Статья 3: Удаление невидимых поверхностей: z-буфер
• Статья 4: Необходимая геометрия: фестиваль матриц
  
  • 4а: Построение перспективного искажения
  • 4б: двигаем камеру и что из этого следует
  • 4в: новый растеризатор и коррекция перспективных искажений
• Статья 5: Пишем шейдеры под нашу библиотеку
• Статья 6: Чуть больше, чем просто шейдер: просчёт теней

Улучшение кода

• Статья 3.1: Настала пора рефакторинга
• Статья 3.14: Красивый класс матриц

---

Official translation (with a bit of polishing) is available here.

---

Постановка задачи

Цель этого цикла статей — показать, как работает OpenGL, написав его (сильно упрощённый!) клон самостоятельно. На удивление часто сталкиваюсь с людьми, которые не могут преодолеть первоначальный барьер обучения OpenGL/DirectX. Таким образом, я подготовил краткий цикл из шести лекций, после которого мои студенты выдают неплохие рендеры.

Итак, задача ставится следующим образом: не используя никаких сторонних библиотек (особенно графических) получить примерно такие картинки:



Внимание, это обучающий материал, который в целом повторит структуру библиотеки OpenGL. Это будет софтверный рендер, я не ставлю целью показать, как писать приложения под OpenGL. Я ставлю целью показать, как сам OpenGL устроен. По моему глубокому убеждению, без понимания этого написание эффективных приложений с использованием 3D библиотек невозможно.

Всем привет!

Две недели назад в Москве прошла очередная встреча CodeFreeze. Нашим гостем стал Евгений Кривошеев, признанный российский эксперт в области архитектуры программных систем, консультант из Scrumtrek/Skilltrek. Евгений прочитал офигеннейшую лекцию по архитектуре, как он любит и умеет.



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

• Точки зрения на систему, или Почему мы слепнем при проектировании
• Адресация ключевых рисков, или Гордыня убивает
• Учитываем контекст, или Как не долбиться в закрытую дверь

Перевод pdf файла с сайта http://www.mcdonaldland.info/ с описанием 23-х шаблонов проектирования GOF. Каждый пункт содержит [очень] короткое описание паттерна и UML-диаграмму. Сама шпаргалка доступна в pdf, в виде двух png файлов (как в оригинале), и в виде 23-х отдельных частей изображений. Для самых нетерпеливых — все файлы в конце статьи.

Под катом — много картинок.

А ваше приложение — RESTful? Чтобы ответить на этот вопрос нужно сначала разобраться что такое RESTful. Бытует мнение, что отдавать правильные коды ответов в HTTP — это уже RESTful. Или делать правильные идемпотентные HTTP-запросы — это вообще очень RESTful. Мы в Хекслете сделали практический курс по протоколу HTTP (отличия версий, отправка форм, аутентификация, куки и пр.), и в нем мы стараемся рассказать о правильном использовании запросов, но нужно понимать, что RESTful это не про HTTP, это вообще не про протоколы интернета. Современный веб и взаимодействие между браузером и сервером с помощью HTTP и URI могут удовлетворять принципам RESTful, а могут и не удовлетворять.

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

Разрабатывая приложения, мы постоянно сталкиваемся с новыми подходами, языками и концептами. И постоянно мы мечемся в сомнениях «смогу ли я быть на волне, оставаться конкурентоспособным, учитывая все изменения и тренды?». Давайте задумаемся на мгновение, вспомнив фразу из моего любимого фильма «Касабланка» — в любви законов новых нет — так создан свет.

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

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

Итак, я просил ответить на вопрос какие книги из статьи вы читали?

Результаты опроса:

Название книги	Количество голосов	Процент
Том ДеМарко. Deadline. Роман об управлении проектами	247	54%
Фредерик Брукс. Мифический человеко-месяц, или Как создаются программные системы	174	38%
Джоэл Спольски. Джоэл о программировании	165	36%
Том Демарко и Тимоти Листер. Человеческий фактор. Успешные проекты и команды	148	32%
Джейсон Фрайд, Дэвид Хайнемайер Хенссон. Rework. Бизнес без предрассудков	108	24%
Джеффри Янг и Уильям Саймон. iКона. Стив Джобс	94	21%
Том ДеМарко, Тимоти Листер. Вальсируя с Медведями: управление рисками в проектах по разработке программного обеспечения	70	15%
Том Демарко, Тимоти Листер. Балдеющие от адреналина и зомбированные шаблонами. Паттерны поведения проектных команд	51	11%
Кармин Галло. iПрезентация. Уроки убеждения от лидера Apple Стива Джобса	48	11%
Патрик Ленсиони. Смерть от совещаний	21	5%
Патрик Ленсиони. Пять пороков команды. Притчи о лидерстве	19	4%
Патрик Ленсиони. Пять искушений руководителя: притчи о лидерстве	16	4%
Патрик Ленсиони. Три признака унылой работы. История со смыслом для менеджеров (и их подчиненных)	11	2%

А теперь еще один бонус — список книг по заданной тематике, которые прислали нам читатели:

Когда я первый раз столкнулся с темой бинарных деревьев в программировании, то сразу нашел на Хабре ответы почти на все возникшие у меня вопросы, но время шло, вопросов становилось больше и совсем недавно я нашел тему, которую еще не осветили на данном ресурсе — это 2-3-4 деревья. Есть отличная статья на тему 2-3 деревьев, в которой можно найти ответы на вопросы «Что такое куча?», «Что такое 2-3 деревья», а также информацию про основные операции со структурой, поэтому я не буду повторяться и сразу перейду к главной теме.

Итак, главное отличие 2-3-4 деревьев от 2-3 состоит в том, что они могут содержать более трех дочерних узлов, что дает возможность создавать четырехместные узлы (узлы, имеющие четыре дочерних узла и три элемента данных). Можно увидеть отличия визуально на гифке под эти текстом.На первом слайде показано 2-3 дерево, на втором — 2-3-4.

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

В компьютерных науках для эффективной реализации очереди с приоритетом используются структуры в виде кучи.

Мы продолжаем серию постов про искусственный интеллект, написанных по мотивам выступления в «Технопарке» Mail.ru Константина Анисимовича — директора департамента разработки технологий ABBYY. Вторая статья будет посвящена алгоритмам поиска.


В зависимости от того, какой способ представления знаний мы выбрали — декларативный или продукционный — мы определяем способ применения знаний. С продукционной системой все достаточно просто: мы непосредственно интерпретируем продукции.

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

Соревнование Back to the Code закончилось и мы получили огромное удовольствие от просмотра различных повторов игр и изучения стратегий в каждой. Мы увидели достаточное количество хороших идей и мы надеемся вы насладились игрой в той же степени, что и мы.

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

Python жив! С такого громкого заявления хочется начать статью.

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



В конце 2014 года мы подводили итоги за год. В этот раз мы рассмотрим тенденции за неполные 11 месяцев 2015-года.

Но перед тем как перейдем к тенденциям — расскажем что сделали за (почти) год.

Интересующихся подробностями милости просим под кат.

Сегодня JavaScript лежит в основе большинства современных веб-приложений. При этом за последние годы появилось большое количество JavaScript-библиотек и фреймворков для разработчиков Single Page Application (SPA), графики, анимации и даже серверных платформ. Для веб-разработки JavaScript используется повсеместно, и поэтому качество кода обретает всё большее значение.

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

Что такое USDT и зачем он нужен
USDT, или Tether, — это стейблкоин. Это значит, что в отличие от обычных криптовалют, цена на него не скачет вверх-вниз. Один токен USDT всегда равен примерно одному доллару США. Почему это удобно? Представь, что у тебя есть биткоины — сегодня они стоят много, а завтра — на 20% меньше. Не очень приятно, да? А USDT стабилен. Это как цифровой доллар, только без банков.

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

Почему именно USDT популярен среди москвичей

Представь себе: ты в Москве, и хочешь перевести деньги родственнику за границу. Через банк — долго, куча проверок и комиссий. А с USDT всё просто: за пару минут токены улетят хоть в Индию, хоть в Аргентину. Без лишних вопросов.

Читая главу «Двоичные деревья» из книги Джона Монгана Programming Interviews Exposed я задумался о том, как чаще всего рекурсию объясняют начинающим программистам: через сортировку, обход двоичного дерева, построение последовательности Фибоначчи и т.д. Неужели нельзя найти пример поинтереснее? Из закоулков сознания вырвался Лисп, который по своей природе неотделим от понятия рекурсии. Более того, небольшой интерпретатор Лиспа — отличный пример для исследования рекурсии.

Каким же будет минимальный интерпретатор Лиспа, написанный на Питоне? К моему удивлению, решение уложилось в семь строк! Свою роль в этом сыграла как выразительность Питона, так и красота и незамысловатость Лиспа.