to post messages and comments.

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

Кстати, последнее время я стал менее религиозен — смотрю не насколько X считается дерьмом и !Ъ, а насколько X удовлетворяет мои потребности. К примеру, я использую несколько приложений на Java, несколько веб-приложений (гугловый ридер и календарь), а так же гуевый емылоклиент. А еще я сосу хуи^W^Wпишу на перле.

Из пяти собеседуемых на должность сисадмина, претендующих на зарплату от $1000, один знает, как пакет с адресом назначения в 8.8.8.8 в IP-заголовке, попадает на шлюз по умолчанию. Ни один не знает, что такое suid и guid аттрибуты. Ни один ни разу не слышал про sticky bit. Один считает, что пароли хранятся в /etc/passwd. Ни один не знает, зачем папке execution bit.
Продолжение следует.

[00:29:10]<Азатот> Kerrigan: веб — это одна большая свалка костылей. у меня атомный бугурт на полчаса от одной только мысли, во что превратили сраную идею языка гипертекстовой разметки. :FDFCRHBGN DJ DCT OTKB, ТРИДЕ, УЕБ-СОКЕТЫ, БЛЯДЬ! Да что уж там, ЕБАНУТЬСЯ, РАБОТА С ОБОРУДОВАИЕМ ИЗ HTML ПИЗДЕЦ НАХУЙ.
[00:29:37]<Азатот> *ЖАВАСКРИПТ ВО ВСЕ ЩЕЛИ
[00:30:17]<Азатот> костыли на костылях костылями погоняют. худшее проявление ненаправленной эволюции ,как она есть.

Все, абсолютно все драйверы, услышав в моей болтовне ключевые слова "компьютер" или "программист" начинают рассказывать о спермопроблемах с своими/детей/братьев/вотевер цомпутерами. Я в спермопроблемах ничерта не понимаю и просто слушаю с умным видом. Выдумать себе штоле далекую от ойти легенду.

Хоть средний айтишник является и не самым приятным зрелищем по жизни (как говорит мой коллега, «два программиста равно половине человека»), все остальные по объективным показателям оказываются в сотню раз омерзительнее.
heller.ru

Я кстати все больше замечаю в своем круге общения людей, горящих желанием попробовать 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. Таким образом привычная “линейная корреляция” между температурой и величиной отказов, как минимум, не подтверждается.

Специализация и профессиональные навыки
Профессиональное владение компьютерными системами на базе
Mops linux, Suse, Linux ALT, SlackWare, RedHart Linux, Linux ASP, FreeBSD, OpenSolaris, Mac OS, Windows 2000-2008 server.
DNS‚ Active Directory‚ DHCP‚ Squid‚ Samba‚ Firewall‚ FTP‚ HTTP‚ Xmail‚ Qmail‚ SendMail‚ Kerio‚ Exchange и др. сопутствующее программное обеспечение‚ установка настройка‚ администрирование.
Разработка политики компании по защите и конфиденциальности информации‚ объединение удаленных офисов в единую сеть (удаленные рабочие столы‚ VPN соединения). Настройка резервного копирования информации.
Знание линеек оборудования Cisco‚ HP‚ IBM и др. Администрирование 1С 6-8‚ юридических программ.
Настройка систем удаленного администрирования всех удаленных офисов из одного централизованного места. Знание АТС предпочтение Panasonic.