to post messages and comments.

← All posts tagged ойти

Я кстати все больше замечаю в своем круге общения людей, горящих желанием попробовать hadoop. Кому-то надо писать неебические количества данных (даже порядок цифр не могут назвать!), кому-то надо делать аналитику. Петабайты блядь у всех.
мало какая еще есть индустрия, где люди так движимы модой

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

Mainframes also have execution integrity characteristics for fault tolerant computing. For example, z900, z990, System z9, and System z10 servers effectively execute result-oriented instructions twice, compare results, arbitrate between any differences (through instruction retry and failure isolation), then shift workloads "in flight" to functioning processors, including spares, without any impact to operating systems, applications, or users.

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

Роль — аналогична классу. Особенно, если Вы будете думать о классах в терминах CRC-карт.

Вот есть такой класс — "архитектор". Корректно говорить в отрыве от системы — нужен вам этот класс, или нет? Корректно ли вообще обсуждать класс, зная только его название — или все-таки он определяется не своим названием, а списком своих responsibilities и collaborators?

Возьмите не одного архитектора, а законченную группу, способную выдать законченный результат. Каждая роль — класс. Каждый человек — объект. Учтите, что объекты могут "обрабатывать сообщения" параллельно (так было в Smalltalk 72, кстати).

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

Вот. С такой аналогией Вы можете применить свои навыки ОО проектирования и рефакторинга для организации разработки — учтите только, что вы "проектируете" параллельную систему без разделяемой памяти. Каждый объект — в своем процессе. Может быть, вообще на разных машинах с медленными каналами. :)

Это достаточно точная аналогия для понимания работы группы людей.

Так, например, многие эксплуатанты, последовавшие рекомендациям ASHRAE <datacenterknowledge.com> (American Society of Heating, Refrigerating and Air-Conditioning Engineers) в 2009 году, пересмотревших свои ранние рекомендации об оптимальной температуре экспуатации оборудования, и повысивших рекомендации эксплуатационной температуры в датацентре до 27 градусов на входе в сервер, вовсе не наблюдали пропорциональное увеличение количества отказов. В подавлящем большинстве случаев сообщается о изменениях этого параметра “ниже измеряемого уровня”. Некоторые, повысившие температуру с 25 до 30 не получили роста отказов на 1,8%, предсказанного по результатам MIL-HDBK 217F. Таким образом привычная “линейная корреляция” между температурой и величиной отказов, как минимум, не подтверждается.