Про железо

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

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

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

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

Чем и занимаюсь.

Архив OpenSUSE xz разворачивать отказался. Fedora 23 не стартует. В форумах нашёл радостные сообщения о том, что в версии 22 удалось дойти до логина. Когда-то в сети был работающий порт версии 21, но ссылка уже давно мертва. Несколько вариантов, в том числе Arch Lunux, на который тоже были большие надежды, раздаются в виде архива. Надо немного подпилить напильником, чего сейчас не очень хочется. С первого раза заработал только какой-то левый вариант Debian и RedSleeve 6. На последнем пока остановился: авторы обещают, что, вместо погони за новизной, сосредоточились на стабильности. Вот только портированных пакетов у них не много и в новой версии CuBox не упомянут.

Это значит, приключения продолжаются...

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

Про ёжика в тумане, зазнайство, языки программирования и вериги

Dragon Dreaming объединяет мудрость индейцев с современными достижениями проджект менеджмента.

Это из рекламы местных курсов. Пусть будет вместо эпиграфа.

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

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

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

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

It is not enough for a modern software development technology simply to be good.

Most IT professionals are paid for their time not for their results. Productivity is not a concern for them.

There is a believe that lazy developers will save the day because they choose most efficient ways. But do not forget: they optimize processes for themselves not for their employers. For instance, they tend to compile big volumes of code to do something really good at the time of waiting by claiming that they are hard working.

On the other hand most tasks developers have to solve today are too boring. They are eager to play with something new. It must be interesting and it must bring personal satisfaction at the end of each day.

If we design tools and methods for software architects and software developers we must consider them as ordinary users. We must create processes and software for imperfect people. We must accept their limitations, disabilities and misbeliefs.

Of course any inhuman technology can be pushed by a loyal management. Someone will rebel. Someone will leave. Others will adapt.

But this only means that they will accept it. It is too naive to hope that they will change for it. Methodologies and tools created for saints are in heaven. (Some are preserved in universities.)

A popular technology must abandon "purity". It must allow a partial introduction, a sloping learning curve, a simplified usage. It must not break or melt in the hell of burning deadlines. It must show "tangible" progress not only by distant milestones but by day-to-day work.

And it also must be fun.