С миру по нитке...

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

• Сегодня предлагаю ознакомится со статьёй История победы на ежегодном соревновании Russian AI Cup 2017
• Ранее - Как написать хорошее решение для Highload Cup, но недостаточно хорошее чтобы выйти в топ
• И ещё раньше, в 2015 году: История победы на ежегодном соревновании Russian AI Cup 2015

UPD: Ссылки на описания от участницы занявшей второе место и участника занявшего одиннадцатое место в 2017 году.

Две интересные статьи про Австралию:

• Австралия: небольшая реколонизация Земли (а ещё в комментариях привели видео с интервью про Австралию)
• RFDS: скорая помощь Австралии с SLA в 1 час до любой точки континента

Upd: ещё одна статья - Кто такие «седые странники» Австралии

Может быть кому-то ещё будет интересно.

На днях попалась интересная статья Директор по здравому смыслу: как перестать все контролировать и начать работать в команде, в которой описывалось "взросление" небольшой компании, и как при этом менялась структура и форма управления. Приведу запомнившуюся мне цитату:

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

https://habrahabr.ru/company/itsumma/blog/342212/

Отличная статья про аспекты проведения Code-review:

Часть 1

1. Отдайте компьютерам скучную часть работы
2. Оформите аргументы по стилю в виде руководства по стилю
3. Начинайте ревью немедленно
4. Начните с высокого уровня, и спускайтесь ниже
5. Щедро используйте примеры кода
6. Никогда не говорите «ты»
7. Оформляйте отзывы как запросы, а не команды
8. Обосновывайте принципами, а не мнениями

Часть 2

9. Стремитесь повысить уровень качества кода только на одну-две ступени
10. Ограничьте фидбек по повторяющимся примерам
11. Уважайте область ревью
12. Ищите возможность разбить большие ревью
13. Искренне хвалите
14. Утверждайте ревью, когда остались тривиальные правки
15. Заранее избегайте тупиковых ситуаций

Интересная статья о визуализации данных:

1. Правильный тип графика
2. Логический порядок
3. Простой дизайн
4. Легкое сравнение данных
5. Минимум элементов
6. Не перегружайте информацией
7. Понятный формат чисел
8. Название и подписи
9. Общепринятые цветовые решения
10. Минимум типов диаграмм
11. Единая цветовая палитра

После прочтения скорректировал несколько своих презентаций.

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

• О культуре разработки в группах программистов
• Сударь, ваша команда — не команда

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

1. Learn X in Y minutes - здесь X - это то, что вы хотите выучить (например, Delphi, Go или даже CSS), а Y - время.
2. Hyperpolyglot - сравнение конструкций "близких" языков программирования (и не только их).

По мере возможности, стараюсь пополнять свой багаж знаний.

Для удобства пассажиров с 1 июля 2017 года реализация билетов «Единый» и «90 минут» на 60 поездок будет осуществляться только на карте «Тройка».

http://mosmetro.ru/press/news/2151/

Из приятного можно отметить, что Метрополитен проводит акцию: с 1 по 30 июня при покупке билетов «Единый» и «90 минут» на 60 поездок пассажиры получат карту «Тройка» в подарок - внесение залога в 50 рублей не потребуется.

PS Почему-то очень напомнило "по просьбам трудящихся" из теперь уже далёкого прошлого.

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

Даже некоторые странности в стандартах (вроде двух пробелов после табуляции — что очень, очень, очень глупо!) намного лучше, чем вообще никаких стандартов.

https://habrahabr.ru/company/infopulse/blog/322418/

Полностью согласен!

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

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

https://habrahabr.ru/post/321852/

Также хочется отметить ещё одно высказывание из этой статьи:

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

PS: с описанным в статье "выпрашиванием" хороших оценок регулярно сталкиваюсь в автосервисе одной известной сети при обслуживании автомобиля.