В журнале IT Manager вышла моя статья "Про моду, гибкость и жизнь". (https://www.it-world.ru/cionews/want/143384.html)
Заметки на полях - или взгляд практика на то, когда могут "взлететь" гибкие технологии.
В журнале IT Manager вышла моя статья "Про моду, гибкость и жизнь". (https://www.it-world.ru/cionews/want/143384.html)
Заметки на полях - или взгляд практика на то, когда могут "взлететь" гибкие технологии.
На Хабре очережная интересная статья: "Что нужно учесть при проектировании системы, чтобы не было мучительно больно?". Статья о том, как много боли можно получить впоследствии, изначально - неверно спроектировав приложение.
Вернее, как "неверно спроектировав". Понятное дело, что когда гипотетическое веб-приложение типа "сайт с некоторыми функциями" делается "для себя" / "для 100 - 1000 пользоваталей", то по большому счету - не очень важно, "синхрон-асинхрон", "прямые права" (не через роли) и т.д. Когда пользователей становится 100 000 - 1 000 000 и выше, эти проблемы начинают "выстреливать", причем - в самый неожиданный момент. Да, кстати, это не только для веба - это в принципе, для многопользовательских приложений. У всех свои "пороги срабатываения проблемы", но то, что проблема "выстрелит" на больших объемах, если её оставить - 100%. Безальтернативно.
Понятное дело, что поначалу никто не планирует "выход на объем", но вот что точно нужно делать в самом начале - как следует проработать архитектуру приложения, с тем, чтобы впоследствии было проще "расшивать" узкие места. Автор статьи, кстати, делает совершенно аналогичные выводы. Не касаясь явно, правда, еще одного момента - а именно объема данных. Косвенно о них говорится в разделе "Масштабирование", но явно - нет. А это, вообще говоря, может быть той еще головной болью. Когда, например, хранилище данных достигает 10000 Тб, и нужно обеспечить быстрый доступ ... или, как вариант, необходимо хранить таблицу в пару-тройку десятков миллионов строк... еще раз скажу, что редко когда на старте думаешь о том, что так будет. Но бывает, и еще как! В одном случае - логирование действий пользователей с ростом их числа съедает всё место, в другом - начинают в систему "заводить" не предназначенный для этого "тяжелый" контент (видео и т.д.). И получается на выходе - тормоза, отказы, 503я ошибка или просто "висим намертво".
Так что мораль: если вы только начали проектировать приложение - думайте о росте. Если приложение уже есть, но в нем еще нет ни пользователей, ни данных - думайте о росте. Потому что если не думать, то "рост" заставит вспомнить о нем сам. И будет существенно больнее.
На E-xecutive попалась интересная статья: 6 токсичных типов сотрудников, отравляющих компанию.
Я вот лично сталкивался с каждым из этих типов. Даже не скажу сразу, какой тип наименее приятен... наверное, всё-таки "Неприкасаемые". Обычно у этих ребят достаточно власти (и дурь, увы, тоже не редкость), чтобы сделать как лучше. Ну а дальше - известный принцип: "не надо мне делать как лучше, сделайте как хорошо". Второй - "жертвы", через их объяснения о невозможности простейшего действия порой не пробиться и с тараном... остальные в моем личном антирейтинге помечены как более безобидные.
И да, интересный вопрос от себя к себе - а я случаем, не в их числе? Вот не хотелось бы...
Пропиарю очередной интересный пост на Хабре: https://habrahabr.ru/post/318002/
Речь идет о реальном опыте внедрения Scrum - зачем, почему и как. Реальный кейс небольшой компании и изложение того, что было и к чему пришли, а также - как этого достигли.
Очень отличается от рафинированных кейсов "Как внедрять Scrum". И именно этим и ценно.
О гибкие методологии сломно немало копий. Кто-то ругает их, кто-то - хвалит. Но факт в том, что они есть, живут и развиваются. А порой понять "why is?" бывает весьма непросто. А тут попалась шикарная статья. буквально на пальцах объясняющая, что такое aglie и с чем его едят. Вот:
Попалась интересная мне статья "Опыт построения и эксплуатации большого файлового хранилища". Просто все описанные проблемы когда-то приходилось решать. Да и вообще, в целом - интересный взгляд на "большие данные". Ну, как на большие данные - автор чётко делит доносит признаки файлового хранилища, и рассказывает. Фактически, это - история граблей и побед над ними. Достаточно подробно (на уровне концепта архитектуры) рассказано, как были побеждены грабли. Что было сделано. Понятно, что know how не раскрывается...
Ссылка: https://habrahabr.ru/company/oleg-bunin/blog/313364/
На Ютубе - отличное интервюью, которое дал Павел Алферов Павлу Софронову, по разработанной им методологии РИМ-3, и, в частности - по концепции контрольных точек. Что очень здорово - Павел прямо и открыто говорит об особенностях национального проектного управления. И о том, как эти особенности "вписать" в живой проект. Честно - восхищен, тем более, что знаю, "как это работает".
Ссылка на интервью:
https://www.youtube.com/watch?t=130&v=BB-TUZ_iHkw
Само интервью: