Category: Программирование

Субботние лекции: Как перестать верить технологиям

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

Как выжить этим отважным парням в таких условиях? Есть на эту тему триптих из трёх лекций.

Первая:

Как ответ на неё последовала вторая:

там он ссылался на эту офтопную лекцию

И финальная третья лекция

Реклама

В чём разница между модульными, интеграционными и функциональными тестами?

Есть большой и постоянный холивор на тему названий для разных категорий тестов. Например вот в статье
Unit and integration are ambiguous names for tests автора предлагает свою терминологию.
И везде принята немножко разная терминология. Например в Grails юнит тесты могут тестировать один класс: сервсис, или контроллер или даже вьюху, но при этом всё что можно мокается а вместо базы используется легковесная имитация на основе ConcurrentHashMap.
В интеграционных тестах у тебя уже появляется спринговый контекст, работает депенденси инжекшен и есть реальная база к которой можно SQL запросы посылать.
Функциональные тесты в Греилс это тесты через Selenium когда запускается реальный браузер и робот ходит и кликает.

Но вообщем говоря всё равно остаётся множество вопросов и на них хорошо рассказал Алексей Речиков в своём докладе «How we testing our software “Google way”»

Слайды

UPD: ещё мне понравился доклад по теме

Как жить на Legacy проекте

Несколько хороших и обязательных к просмотру лекций про то как разрабатывать и сопровождать старые легаси проекты.
Кстати тут нужно сказать что legacy — это переводится не просто как «наследство» а как некий дар, например когда бабушка передаёт внучке кольцо. Авторы термина хотели заложить какое-то позитивное значение 🙂

На эту тему почти на всех конференциях рассказывает Виктор Полищук:

Примечательна также классификация которую Виктор использует:

What is…

  • Very old projects, had been written long long ago.
  • The Highlander: Old mature projects, had been written ages ago. Optimization required.
  • Paragon: Die Hard Nobody knows why it is still alive.
  • Fashion or market victims: Nobody wants this sh%t anymore.
  • Problem Child: Nobody loves it. Sentenced Customer tired of supporting it, everything is up to you.
  • Apathetic: Nobody cares

What is usually NOT…

  • Badly written projects which are not in production.
  • Low quality designed projects.
  • Small projects.
  • Every project you don’t understand.

legacy code - переписать это говно мамонта

Виктор Полищук — Все что вы хотели знать о Legacy-коде, но стеснялись спросить

Виктор Полищук — Legacy: как победить в гонке

И этот доклад вдохновил ребят из ДатаАрта сделать свой доклад:

И продолжение «Travel, Legacy and SWAT. Q&A Session»

Презентация Michael Feather, автора книги Работа с унаследованным кодом:

Дмитрий Миндра: Refactoring Legacy Сode

Virtual JUG: Testing and Refactoring Legacy Code

Сергей Немчинский — Как создаются и поддерживаются Enterprise.
Очень хороший доклад где раскрывается суть легаси проектов, как они возникают и какая у них специфика.

Статья Практика рефакторинга в больших проектах в сотый раз о вечном. Для тех кто ещё халтурит и не прочёл замечательную книгу Working Effectively with Legacy Code

Ну и несколько интересных статей на окололегасиную тематику:
* Что иметь в виду при переписывании программного обеспечения
* Читайте код, с остальным справится компилятор
* Рентабельный код
* Поиск и чтение унаследованного кода

Небольшой конспект с добавлениями моих мыслей.
1. На легаси проекте всегда есть несколько параллельных подходов и технологий. В разное время были попытки и не всегда законченные сделать что-то правильно не выкидывая старого. Например если у вас был старый API и вы решили сделать новый — то у вас есть новый АПИ но клиенты всё равно используют старый потому что в нём были фичи которые вы в новый переносить не будете или ещё не решили как его сделать правильно. Точно также если у вас был JSF и вы решили переписать на Spring MVC то теперь у вас половина кода на Спринге и половина на JSF.
На моём текущем проекте живут одновременно чисто сервлеты, чисто JSP, JSF, JSP + Tiles, немного Velocity, Spring 3.0.7 и мы даже не можем перейти на Спринг 3.1, куча контролеров на Tapestry 4 (к которому уже даже документации не найдёшь), и Tapestry 5.0 который по сути совсем другой фреймворк и мы не можем даже переписать на Tapestry 5.3, просто потому что уже никто его не знает.
Всё это живёт одновременно и активно используется. Всё находится в полупереходном состоянии потому что пока начали переписывать и делать новые ошибки, вдруг выяснилось что чего-то сделать на новом практически невозможно и вообще уже наделали новых ошибок что уже и переписывать так пожалуй не стоит. Всё это устарело и затраты на обновление больше чем на переписывания с ноля.
Из-за версионного просака обновится невозможно. И иногда нужно просто смириться что это останется таким навсегда (привет Кобол программистам).
2. На лагаси проекте очень многое можно просто выкинуть. Очень много нуждается в оптимизации. Но как понять что можно менять а что нет? Как найти проблему? Т.е. здесь на первый план выходит и самое принципиальное это знать как используется программа: вам нужен мониторинг, вам нужно сборка и визуализация логов (logstash+elastic+kibana), или статистика юзаджей, вам нужен доступ к базе на продакшене, вам нужен доступ ко всем конфигам а то и вовсе к серверам. Насколько только это возможно. Именно с этого и следует начинать первым делом.
Допустим ты ковыряешься в коде и видишь кучу проблем связанных с тем что у вас регистрозависимые (case sensitive) логины пользователей, т.е. User и user это два разных пользователя. Потому что дальше ваша система шлёт эти юзернеймы через АПИ в другую систему которая их не поддерживает. И ты должен иметь возможность прямо сейчас посмотреть в конфигах включена ли эта возможность, посмотреть в базе как много пользователей с дублицироваными юзернеймами. Нужно погрепать логи как много пользователей столкнулось с этими проблемами.
Нужно поискать по истории ревизий кода когда добавлялся этот функционал и зачем. Нужно расспросить всех коллег кто что-то знает про это.
Т.е. на легаси проекте для того чтобы сделать какое либо изменение порой требуется настоящее и полноценное исследование, расследование, с допросами и большой археологической работой по изучения пластов кода и поиском то ишью трекеру.
Какая нибудь заброшенная страничка на Вики тебя может реально выручить. Отсюда следует следующий пункт…
3. Всё что только можно нужно записывать и потом никогда не выбрасывать. Желательно любые обсуждения и митинги потом записывать хотя бы тезисно и рассылать по почте, и её, корпоративную почта нужно беречь и лелеять. Возможно даже вам следует хранить логи и бекапы бд баз хотя бы за год. «Чем больше бумаги тем чище жопа». И не бойтесь что создаёте мусор — археологи по мусорным кучам восстанавливают знание о целых эпохах цивилизаций.
Просто поймите — даже самые очевидные для вас вещи следует записывать потому что команда совершенно точно поменяется полностью. Это всё равно что представьте что послезавтра весь ваш код, всю вики, все письма, весь репозиторий просто передадут на разработку в другую компанию.
4. На Вики писать и перечитывать\переписывать\обновлять статьи это абсолютно обязательная работа ничуть не меньшая чем писать код. Тикеты в ишью трекере периодически нужно проходить и перечитывать. Реально очень многие проблемы, уж поверьте, давно известны и даже были попытки их исправить. Это нудное занятие вам сэкономит кучу времени. Но читать их следует только после того как вы уже хоть немного разобрались с проектом, иначе вы не поймёте о чём там вообще идёт речь.
Дело в том что на легаси проекте из-за большого числа джира тикетов по закону больших чисел вы практически наверняка там точно есть практически все баги и проблемы, и вы можете достаточно точно оценить ситуацию с разными компонентами системы.
В совокупности с письмами из сапорта и логами это даёт хорошую картину на весь проект. Это важная метрика которая вам поможет вам понять размер трагедии.
5. На любом легаси проекте почти наверняка есть огромные проблемы со сборкой проекта. Обычно она не тривиальная, требуется ANT и Maven конкретной версии, собирается проект почти наверняка только под шестую джаву, требуются ручные действия. Билд долгий, тесты blinking (то падают то нет) и очень много из низ вообще отключены через @Ignore. Есть самодельно пропатченные версии библиотек. И это вам очень сильно повезёт если проект мавенизирован и зависимости вообще известны и доступны с Maven Central репозитория.
Из-за того что у вас много либ (а их наверняка много) а у вас нет возможности дать каждой свой classpath, у вас точно есть куча проблем с конфликтующими или дублирующимися зависимостями.
И для успешной жизни на проекте вам следует опустится вот это вот болото Мавена и стабилизировать билд. Это второе по важности после логов и мониторинга и метрик что следует сделать.
6. Любой код без тестов автоматически становится легаси. Ваша задача любой ценой покрыть код тестами. На каждый баг — покрываете то место тестами. Вплоть до драконовского правила не принимать новый код без тестов хотя и без фанатизма. Да, вам придётся замокать пол мира, написать кучу фикстур и стабов, написать долгие интеграционные тесты которые пол базы загрузят, но без этого вообще никак. Когда создавалось множество легаси проектов тогда тестирование ещё не было принято как промышленная практика или фреймворки которые были тогда не очень были рассчитаны на то что их нужно будет как-то тестировать. Сами тестовые библиотеки и техники с тех пор прошли большой и мучительный путь, и в каждом фреймворке уже изначально идёт куча вспомогательных классов и стабов и документации о том как тестировать.
Поэтому на легаси проекте это совершенно нормальная практика когда функционал написанный\исправленный за час вы в три раза дольше покрываете тестами. Постепенно самое гадкое вы всё таки покроете тестами а ваша архитектура всё таки начнёт постепенно становится лучшей для тестирования. Это трудозатратный путь, но он оправдан и рано или поздно принесёт плоды, просто верьте.
7. Дальше нужно улучшить логирование — подчистить лог от огромных стектрейсов и пофиксить то что их продуцирует. Дописать логи везде где только нужно, все входящие и выходящие реквесты в АПИ тоже логировать. При этом нужно сделать так чтобы логирование имело смысл по максимуму. Также в логах у вас почти наверняка будет множество секьюрной информации: пароли пользователей и ключи от АПИ, номера кредитных карт или что нибудь ещё такое чего там не должно быть. Представьте что ваши логи взломали хакеры — вы должны максимально им усложнить жизнь.
8. Улучшить мониторинг — через JMX пробросить все важные метрики: количество активных сессий или реквестов. Повключать всякие опции JVM для мониторинга. Об этом Виталий Тимчишин рассказывал в клубе анонимных программистов презентация, видео (часть 1), видео (часть 2) но лучше новую инфу поискать, особенно про FlightRecorder.
9. Билд нужно ускорить и улучшить насколько это возможно. У вас должен быть самый лучший CI tool — TeamCity. Собираться в нём должно всё что только может быть собрано.
10. Вам нужно ввести версионирование БД и db migration tool — DBMaintain, FlywayDB, LiquiBase.
11. Грамотно разнести тесты как в Гугле поделить их по времени выполнения. Тут ключевой момент в том что если для TDD разработки ваш тест должен отрабатывать быстро (максимум 15 секунд) иначе она не приживётся. Сам билд в CI тоже нужно ускорить как только можно (запуск тестов в параллели, использовать in-memory file system).
12. У вас совершенно точно будут множество проблем с базой данных — конекшен пул будет забиваться, будет множество проблем с уровнем изоляции транзакций, запросы будут долго тупить, N + 1 проблемы, данные будут неконсистентными итд. Эти проблемы нужно чётко методично разруливать — обновить либу Tomcat JDBC Connection Pool, загнать всю работу с базой строго в рамки DAO, самые используемые и статические данные закешировать и сделать так чтобы кеш можно было сбросить через JMX или JavaMelody.
13. Саму базу тоже как правило следует подчистить и хорошенько нормализировать. Делать это нужно очень аккуратно и осознано и обязательно основываясь на реальной статистике. Для PostgreSQL есть утилита pg_stats. По ней можно определить как данные используются и сравнив с кодом можно понять свойства данных: как часто они изменяются, как часто они инсертятся или они read only. Где нужно натянуть индексы. Это очень принципиально потому что даёт нормальный прирост скорости и вообще от данных следует отталкиваться.
14. Дальше вам следует возвести китайскую стену между старым кодом и новым, как рассказывал Витя Полищук. У вас должно быть чёткое понимание что в этой части системы мы пытаемся создать островок удачи и везения, где всё прилично и правильно и после этого перетащить на этот остров весь функционал из плохого кода. Этот островок может быть совершенно отдельным модулем\микросервисом отделённым чётким API и интерфейсами. И жёстко следить за тем чтобы в нём был порядок.
У меня например на проекте например даже уволили сотрудника за то что он не стал переписывать старый функционал а за уши притянул его скопипастив код в островок удачи. Теперь нам оставшимся сцыкотно там гадить.
15. Всё что только можно резать на модули, модули выделять в микросервисы которые общаются по простому протоколу типа REST или JSON-RPC.
У вас наверняка есть часть системы и код который никогда уже не перепишешь и всё что можно с этим сделать — только выделить эту гангрену в отдельный модуль.
16. Memento mori — вам следует честно и сразу думать даже о новом функционале как о выброшенном позже и заранее думать о том как его убрать. Микросервисы как раз неплохо решают эту проблему.
17. Стоит максимально улучшить процесс деплоя — для начала достичь zero downtime но конечно в идеале вообще continuous deployment, но даже не мечтайте 🙂 Даже без zero downtime ваш цикл комит — старт сервера должен быть максимально маленьким. Суть в том что если вы начнёте что-то менять то вам придётся постоянно выкатывать хотфиксы которые фиксят баги после ваших фиксов багов. Если вы начнёте наводить порядок на легаси проекте, да даже просто что-то делать особо ничего не трогая, всё равно у вас будут всплывать проблемы и их нужно будет фикисть по горячему.
18. Если у вас есть внешний API то вам следует проксировать его через фасад где чётко вести статистику кто его дёргает и как. Далее если ваш АПИ будет меняться вам следует самим сделать SDK где вы его сами заимплементите. Всё таки это относительно редкость когда клиенты вашего АПИ используют что-то другое кроме PHP, Java или JavaScript, ну или что там у них. Поэтому вы можете сами написать или попросить клиентов поделится с вами их обвёртками над вашим АПИ и сделать его своим официальным. Далее вы можете менять и экспериментировать с АПИ при этом каждый раз выкатывать новую версию SDK. Т.е. это вам даёт дополнительный рычаг гибкости.
Кроме того попытаться заимплементить ваше собственное АПИ очень хорошо поможет вам понять как мучаются ваши клиенты и заметить частые ошибки.
19. После этого можете пробовать постепенно обновлять ваши библиотеки зависимостей на новые версии, тщательно и внимательно просматривая их чейнджлоги и ища всякие баги которые есть с этой версией. Реально в интернете вы уведите много релевантной информации. Первым делом обновлять следует тестовые библиотеки, особенно моки (EasyMock, Mockito) потому что они изменяют байткод. Проверить что тесты проходят как и ранее и не сломались.
Далее следует обновлять сами плагины Мавена — это тоже довольно опасная операция как оказалось на практике.
После этого утильные либы: Apache Commons Lang, Apache Commons Collections, Guava, JodaTime, Jackson, итп.
Потом можно попробовать проайпдейтить Quartz который в основном используется для джоб и другие либы типа Apache POI чья поломка для пользователей пройдёт почти незаметно.
Потом нужно проадейтить те либы которые делают инструментацию байткода и всякую магию: Hibernate и куча всего другого. Это самое злобное.
После этого можно пробовать перейти на новую джаву.
После перехода на новую джаву можно выкинуть JodaTime и JodaMoney и кучу другого хлама. И обновить остальные либы типа Спринга.

Продолжение следует

Программерия - это алхимия

Программерия, или что нужно знать программисту

Как стать программистом? Что учить программисту?

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

Похожие статьи

Итак, вы решили стать программистом
Что нужно знать каждому программисту по версии Google! (eng)
Программирование — занятие не для каждого
Писать код уже не достаточно: обязанности современных back-end разработчиков
Как стать программистом?
Путь программиста: через что придется пройти джуниору, чтобы стать синиором
Путь программиста
Карта программиста
Что должен знать html-верстальщик?
Почему разработчик — не инженер

Что сегодня посмотреть программисту вместо сериалов

Ну как там у вас воскресенье проходит? Если есть свободное времячко я вам советую посмотреть эти видео которые мне оказались интересными.

Иконоборцы (Iconoclasm — Ted Neward)

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

Языковая сложность — Александр Пиперски

Небольшой рассказ лингвиста о том как пытаются сравнивать естественные языки по сложности и почему в этом зачастую нет смысла.
Довольно интересно если проводить аналогию с языками программирования.Это хорошая метафора, например Китайский — как ассемблер в котором вместо иероглифов машкоды. Но есть, конечно множество различий использования естественных языков от компьютерных. Например в компьютерных тебе очень важна структура, однозначность и возможность легко изменять написанное. В естественных языках важнее скорость передачи мысли и всегда имеется контекст из которого можно востановить значение.

«Uncle» Bob Martin — «The Future of Programming»

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

Виктор Полищук — Legacy: как победить в гонке

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

Парное программирование — Сергей Бережной

Очень просто, для джуниоров, толково и наверное почти полностью раскрытая тема как работать в паре и почему иногда это работает просто супер а иногда совсем нет.

Командная строка Unix — Виктор Ашик

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

Decision Tables and Decision Trees

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

Евгений Кривошеев — Осознанность проектирования

Мы много говорим про архитектуру систем но что она есть сама по себе мы слабо представляем.
Узнал про Cynefin Framework, потом как нибудь изучу его.

Николай Алименков — Современный взгляд на реализацию классических дизайн-паттернов в Java

Патерны проектирования появились давно как некие конструкты которые мы делаем в коде но при этом не можем явно выразить ограниченным синтаксисом языка. С тех пор много воды утекло, часть патернов себя отлично зарекомендовали другие же стали практически антипатернами. Да и синтаксис Джавы очень сильно обогатился и теперь стоит их пересмотреть с учётом нашего опыта.
Отличная лекция для более менее опытных программистов.

Антон Кекс — Цифровая подпись в Java, Россия vs Эстония

Эстония проделала огромную работу в информатизации общества и эстонец Антон Кекс рассказал как у них всё это работает и как внедрять нам.
Очень круто и просто рассказал про такие сложные вещи да ещё и покодил. Я прям захотел себе получить электронное резеденство Эстонии

Презентация интернет магазина Алексея Земскова ZemsMarket.ru

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

Show me yours…

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

Как определить ставить ли новую Windows или любую другую программу

Эволюция Корзины

Среди IT-специалистов распространено мистическое убеждение:

Считается, что каждая четная версия Windows выходит у Microsoft неудачной, а каждая нечетная, наоборот, хороша. Здесь стоит вспомнить критику Windows Millenuim, Windows Vista и Windows 8, которые были четными, а также успех Windows XP и Windows 7. Microsoft пропустила цифру «девять», сделав Windows 10 нечетной в этом списке. Впрочем, некоторые специалисты «девяткой» считают Windows 8.1, что переводит «десятку» в совсем другую категорию.

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

Вспоминаем: после XP люди ждут очень перспективной ОС с ещё более красивой графикой, гиберацией, повышенной безопасностью и возможностью не перезагружать комп после установки программ или драйверов. Появилась Vista. Люди негодуют — глюки, производительность никакая и т.п.
Разработчики чешут репу, многое отключают в системе чтобы не мешало, исправляют баги, что-то добавляют и выпускают семёрку.
Пользователи смотрят — производительность лучше чем у висты, радуются и забывают, что XP работала быстрее (момент немного спорный) и требовала намного меньше ресурсов для компьютера.
microsoft начинают воевать со старушкой XP, так как она остаётся неплохим конкурентом семёрке и активно используется в Китае вместе с IE 6

Сейчас повторяется то же самое: обещают поддержку ARM процессоров и телефонов, совместимость со старыми приложениями и возможность играть в игры для Xbox, революционный интерфейс и т.п.
Когда восьмёрку выпустят внезапно поймут что погнались за двумя зайцами, есть много багов, на телефонах тормозит и т.п. и т.д.
Разработчики почитают гневные реплики пользователей и к следующей (наверно, девятой) версии всё исправят. Судя по всему, ещё лет пять-десять как минимум семёрка будет оставаться одной из используемых ОС для компьютеров.

Впрочем, неудачная (если вдруг) Windows 8 не понравится некоторым пользователям, и они перейдут на linux или продукцию компании Apple, которая в последнее время имеет свободных денег больше чем microsoft. Не будем забывать и про Google, которые, в принципе, тоже могут что-то выпустить.
(с) http://forum.boolean.name/showthread.php?t=15523

ИЧСХ и всё прямо так и случилось!

Молоток как эволюция Виндовс

Поэтому есть релизы стабильные или успешные а есть тестовые или неуспешные. Понять успешность можно лишь по статистике как быстро на него переходили («адоптировали»). Я например за вистой и восьмой виндой даже не поработал. Иногда когда вижу у кого-то удивляюсь что это такое.

И это касается не только Виндовс но и других крупных продуктов с длинным релизным циклом, обычно у «коробочных» типа Microsoft Office. Но есть интересный пример версии Java:
1.0 Её даже не публиковали, так что скипнем
1.1 Первая опубликованная, ажиотажа не вызвала. Помещалась на дискету. Можно считать релиз неуспешным.
1.2 Появились коллекции, JIT, Swing, Java plugin и аплеты (а тогда это был крутяяяк) — количество кода библиотек выросло в три раза и уже на дискету не влезало. Успех!
1.3 Вообще ниочём, багфикс. Неуспех.
1.4 Регекспы, уродский логинг АПИ, но зато NIO, криптография, XML парсинг. Вроде ничего такого особого, но Успех. Началось активное использование для веба, сформировались библиотеки и фреймворки, появились первые JVM языки Groovy и Scala.
1.5 Синтаксический сахар (статик импорты, аннотации, for each, enum, varargs) но главное что появился внятная Java Memory Model и Concurrency. Внезапно успех, хотя почти на всех старых джава проектах этот на этот сахар ещё не переписали. Но грамотно заложенная и чётко специфицировання JMM сыграла
1.6 Последний релиз Sun’а ничем не интересный кроме внятных процессоров аннотаций. Всё замерло на этом релизе надолго и все только и любая магия так и делалась на аннотациях пока по ночам мы плакали в подушку мечтая о лябдах. Тем не менее релиз оказался довольно стабильным и всё работало много лет, так что всё таки успех.
1.7 Первый релиз Оракла. Ничего интересного, просто промежуточный перед восьмой джавой. Неуспех.
1.8 Ляяямбдыыыыы! И наконец-то внятный Date API. Все перешли на восьмую почти мгновенно. Успех!
1.9 Уже на выходе, по сути будет только улучшена модульность что конечно тоже сверхважно для древних энтерпрайзных монолитных проектов, но хипстеры уже всё говнокодят на микросервисах где всё проще переписать и не нужно сильно запариваться архитектурой. Так что особо ажиотажа особого не будет.

Итак, тут закономерность чётности версий прослеживается ну только при очень большом старании. Но если посмотреть не каждую вторую, а каждую третью версию то можно заметить что 1.2, 1.5 и 1.8 то эти релизы были особенно успешными. Причём даже не так, они наделали шума. В основном из-за того что в них появлялись новые «Вау» фичи. И это принципиальное дело кстати.
Представьте себя менеджером продукта. У вас есть некие срочные задачи — например секьюрити уязвимости, есть задачи по долгосрочному плану улучшения архитектуры проекта, но периодически вам нужно добавлять в продукт что-то такое что снова привлечёт внимание пользователей и даже те кто пользовался древней версией и довольны захотели бы купить новую версию. Например в случае с Джавой это новые возможности языка.
Т.е. есть разные задачи с разными характеристиками по важности и срокам и при грамотном менеджменте ты их учитываешь. Если их граммотно разложить и расписать на графике то можно найти множество таких закономерностей и предсказывать свойства следующей версии.
Поэтому можно смело предсказывать что например в десятую версию Джавы будут внесены какие-то вау фичи.

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

Но не всегда четно-нечётная схема усложняется, многие как раз наоборот стараются перейти к более частым и но последовательным и плавным rolling releases и continuous delivery:

Между сериями 1.0 и 2.6.x ядро Linux использовало нечётные номера для бета-версий, и чётные — для стабильных. Например, Linux 2.3 был серией в разработке, а Linux 2.4 — серией стабильных релизов, в которую перерос Linux 2.3. В номере релиза Linux kernel сначала писался номер второстепенной версии, а затем номер релиза в возрастающем порядке. Например Linux 2.4.0 → Linux 2.4.22. После релиза 2.6 в 2004 году Linux больше не использует эту систему, теперь цикл релиза намного короче. Сейчас они просто увеличивают третье число, используя при необходимости четвёртое.

Тоже самое кстати происходит и с броузером Chrome а позже и с Firefox’ом. Какая версия Хрома уже никто не знает (у меня например уже 16.3.0.6796). Для обеспечения надёжности они просто создали отдельную «вечную бету» которую могут себе поставить и протестировать все желающие и Feature toggling.

Непрерывная поставка
Таким образом цикл релиза и фидбека ускорился и подобные схема рано или поздно будет использована почти во всех программах.
И вы не отставайте 😉

ржавые часы

А у вас есть баги на переход к летнему времени?

Сегодня на работе внезапно упал билд — не прошёл один тест на какой-то древней странице админки. Тест был простым и проверял функциональность фильтра по дате. Есть метод который проверяет что между двумя датами есть хотя бы один день. И код примерно такой:

/** Minimal range between dates is one day */
boolean checkMinDatesRange(Date dateFrom, Date dateTo) {
  long millisecondsBetween = dateTo.getTime() - dateFrom.getTime());
  int daysBetween = millisecondsBetween / (1000 * 60 * 60 * 24); // roundinig to int
  return daysBetween >= 1;
}

Как вы уже могли догадаться это воскресенье было последним в марте и перевели стрелки на час вперёд, на летнее время.
В результате millisecondsBetween стало меньше на 36000 миллисекунд и после округления до целого daysBetween стал равен нолю а не ровно один, как ожидал тест.
Отчасти этот код вызван тем что в Java долгое время было просто ужаснейшее Date API и в каждом проекте появлялись свои DateUtils кишащие такими проблемами.

Лечится это через JodaTime или JavaTime примерно так:

int daysBetween = Days.daysBetween(dateFrom, dateTo).getDays()

Тебе ещё не страшно?

Хорошо что этот баг был не критичным, но я уверен что почти в каждой системе есть подобные баги. Например ещё несколько реально случаев с которыми я сталкивался:

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

И такие приколы не только с переводом стрелок, а например с високосным годом, или високосной секундой.
И ладно если вы это ещё кое-как всё написали правильно, но может быть такое что часы не перевились, а то и вовсе батарейка в BIOS села и часы всегда показывают один и тот же день.

А теперь представьте что на АЭС перегретый реактор начнёт гасится графитовыми стержнями на час позже из-за того что часы перевелись на час вперёд? Или поезда на встречу друг другу выехали.
Я программист, и видел уже достаточно кода чтобы боятся таких катастроф.

Например в прошлом году секунда координации вызвала сбои в работе Android, Twitter, Amazon, Netflix и других крупных компаниях где работают весьма толковые программисты.

И это кстати интересная проблема возникает с этой секундой — Земля то, постепенно затормаживается. И потенциально может перестать крутится вообще (т.е. в сутках будет бесконечное число часов), или крутится в обратную сторону (отрицательные часы). Тогда как вообще считать время?

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

Переводим время на перевод времени

И если с секундой координации никуда не деться, её всё равно куда-то придётся приписывать, то вот переходы на летнее и зимнее время это одно из самых дебильных введений.
Зачем переводить? Официально говорят «ну чтобы энергию беречь». Так а как вы её сбережёте? Всё равно свет будете включать когда потемнеет, а не когда часы скажут. График работы тоже можно корректировать не обращая внимание на время. Всё равно, например рестораны, летом работают дольше.
Фермеры всё равно будут вставать с петухами.
Ну допустим, это удобно что у всех организаций синхронно меняется график.
Но почему тогда перевод стрелок только два раза в год? Летом же солнце всё равно в четыре встаёт, даже с учётом сдвига. Так давайте каждый день переводить стрелки? Чтобы наверняка с первыми лучами все шли на работу. Например в Японии в ответственных случаях работа должна начинаться только через 2 часа после восхода солнца, например, при сдаче экзаменов.

А как быть с теми кто в Заполярье если у них вообще белые ночи и дни? Или тем кто на экваторе, они вообще разницы не заметят.

Ладно, допустим они решили всё равно ввести переход на летнее время. А они вообще подумали как уговорить весь мир перейти тоже?
Вот мы и имеем что в разных странах, да даже в разных областях и провинциях по разному. И разница во времени получается по несколько часов разницы во времени.

Это абсолютный бред и у меня с детских лет кошмарное ощущение что вокруг одни идиоты которые этого не замечают.

Эту дурь придумал какой-то британский мудак которому, видите ли, было обидно в гольф играть в темноте. И вместо того чтобы раньше приезжать он решил что всем нужно под его дудку плясать. Целую жизнь на это положил, не зря прожил, герой.

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

ИЧСХ все такие прям умные и прогрессивные что-то там якобы считают а по факту потом просто какие-то мудаки у власти принимают решение о переходе просто так, с бухты-барахты.
Сначала во после революции 1917го года матросы начали декреты вводить и выводить. Ну ладно, это была эпоха модерна.
Но блин, уже в наши дни цирк продолжился: «На встрече с молодыми учёными 8 февраля 2011 года президент Медведев объявил о своём решении отменить ежегодный перевод часов, начиная с отмены возврата на «зимнее» время осенью 2011 год. В соответствии с этим решением были подготовлены и приняты Федеральный закон «Об исчислении времени» и постановление правительства. Летнее время осталось в качестве постоянно действующего».
Вот так, царю взбрело в голову и быстренько приняли закон какой надо. Только дебилу было невдомёк что правильное время — это зимнее, а не летнее.
Но кого такие премудрости интересуют, верно?Ввели сразу и бесповоротно, естественно бюрократы не спрашивали у технарей проверили-ли они свои программы и системы. Сколько сбоев и убытков было принесено, а возможно и жизней, никого не интересовало.
Зато опять провели важное исследование и соцопрос где выяснилось что «реформа не нашла поддержки у значительной части населения». Да ну?

Но цирк на этом не закончился, и говно полетело по трубам:
«Вскоре за Россией последовала Белоруссия.
Верховная Рада Украины 20 сентября 2011 года отменила переход на «зимнее» время с целью сохранить летнее время постоянным, однако 18 октября 2011 года отменила своё решение, и перевод часов состоялся в положенное последнее воскресенье октября. (Успели, бараны, отменить за неделю до перевода).
Вслед за первоначальным решением Украины, и мотивируя решение необходимостью жить в одном времени с Украиной, от перевода часов отказалось Приднестровье. Но потом, вслед за Украиной, в Приднестровье перевод часов был продолжен.»

Но и на этом цирк не закончился и в 2014м году в РФ вернулись на постоянное «зимнее» время.

Я это всё наблюдал внимательно каждый раз всё больше и больше офигевая.

Программист помни: время безжалостно к нам

Изучи матчасть, хотя бы эту:

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

Знай, что в любой момент эти безумные твари снова захотят отвлечь лохов и поменяют часовой пояс или сделают тебе осеннее время. Или оккупируют тебя, например.
Следи что в твоей системе обновляется tz database и обрати внимание чтобы даты в ОС и БД совпадали, как и на других серверах. Учти что ОСи могут тоже долго не обновлять и тогда нужно делать конфиги или хранить их в БД.

Не верь что всегда будет 24 часа. Не рассчитывай вообще ни на что. Когда нибудь, в Землю обязательно врежется астероид и это изменит траекторию.

И помни, грядёт 2038 год!