в пизду, я заебался как школьный дрочер искать кряки и слушать при этом сказки что компания захватит IT мир
lwn.net
и подумайте
все архитекторы, ваннаби и просто девелоперы почитайте и подумайте
мало какая еще есть индустрия, где люди так движимы модой
royal.pingdom.com
Big data has become one the new buzzwords on the Internet. It refers to the massive amounts of data that many modern web services deal with. This post will list some of the more useful software available to web developers for working with big data.
Big data has become one the new buzzwords on the Internet. It refers to the massive amounts of data that many modern web services deal with. This post will list some of the more useful software available to web developers for working with big data.
businessinsider.com
урл опять самоописательный
урл опять самоописательный
вот кстати да. ебаные rfc со своими should привносят разброд и шатание
would read again ccr.sigcomm.org
"куда хуже, что как бы поощряется стыд незнания чего-то (пусть и элементарного) в почти любой профессиональной среде. мне всегда смешно смотреть, как профессионалы устраивают срач и кидание ссаными тряпками. при том, что часто реального креатива в хаосе и боевых условиях, скажем, стартапа от "прожженых профи" как-то и не наблюдается вовсе. ровно потому что человек боится признаться, что в чем-то он вовсе и не профи даже."
не организационные а именно технические причины какие?
дискас
Роль — аналогична классу. Особенно, если Вы будете думать о классах в терминах CRC-карт.
Вот есть такой класс — "архитектор". Корректно говорить в отрыве от системы — нужен вам этот класс, или нет? Корректно ли вообще обсуждать класс, зная только его название — или все-таки он определяется не своим названием, а списком своих responsibilities и collaborators?
Возьмите не одного архитектора, а законченную группу, способную выдать законченный результат. Каждая роль — класс. Каждый человек — объект. Учтите, что объекты могут "обрабатывать сообщения" параллельно (так было в Smalltalk 72, кстати).
Нарисуйте разные варианты, и потом — наложите типичный юзкейс, посмотрите, как будет это работать в динамике. Учитите, что "вызов метода" в данной системе — дорогая операция, ибо данные идут "через границу процесса", с маршалингом. И что объект без содержательного состояния — это плохой объект.
Вот. С такой аналогией Вы можете применить свои навыки ОО проектирования и рефакторинга для организации разработки — учтите только, что вы "проектируете" параллельную систему без разделяемой памяти. Каждый объект — в своем процессе. Может быть, вообще на разных машинах с медленными каналами. :)
Это достаточно точная аналогия для понимания работы группы людей.
ASHRAE (American Society of Heating, Refrigerating and Air-Conditioning Engineers) в 2009 году, пересмотревших свои ранние рекомендации об оптимальной температуре экспуатации оборудования, и повысивших рекомендации эксплуатационной температуры в датацентре до 27 градусов на входе в сервер, вовсе не наблюдали пропорциональное увеличение количества отказов. В подавлящем большинстве случаев сообщается о изменениях этого параметра “ниже измеряемого уровня”. Некоторые, повысившие температуру с 25 до 30 не получили роста отказов на 1,8%, предсказанного по результатам MIL-HDBK 217F. Таким образом привычная “линейная корреляция” между температурой и величиной отказов, как минимум, не подтверждается.
Так, например, многие эксплуатанты, последовавшие рекомендациям