Читаете ли вы бизнес-блоги, в которых автор раз за разом описывает свои неудачи?
Нет, потому что вы хотите перенять успешный опыт, а не узнать о полученном опыте от парня, который сам еще не преуспел.

Однако, тот факт, что вы изучаете только опыт успешных людей, может представлять большую проблему, чем кажется.

Приведу несколько историй, которые помогут понять серьезность этой проблемы.

Следы от пуль

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

Желая увеличить вероятность возвращения экипажей домой, британские инженеры изучали расположение следов от пуль. Инженеры считали, что в тех местах, где больше всего попаданий, нужно дополнительно бронировать корпус самолета. Разумеется, была найдена закономерность: много следов располагалось на крыльях, хвосте и в районе хвостового пулемета. На кабине пилота и топливных баках следов было мало.

Логично заключить, что нужно добавить брони в тех местах, где больше всего следов. Но это неверно.

Это интервью Криса Уонстрота, CEO и сооснователя Github. Данное интервью — часть серии “Bootstrapped, Profitable, & Proud” о компаниях с выручкой более миллиона долларов, обошедшихся без венчурного финансирования на старте и приносящих доход.

Один из довольно частых вопросов на различных околониксовых ресурсах — вопрос о том, какую схему разбивки дисков использовать. С виду простой вопрос на самом деле таит в себе множество подводных камней. Если, конечно же, дело касается серверов. На десктопах все гораздо скучнее и серее.

Универсального решения в данном вопросе нету, просто есть некоторые аспекты, которыми следует руководствоваться при выборе схемы разбивки.

На блоге одного из создателей Aquaria и Spelunky есть любопытный пост с советами для тех, кто испытывает проблемы с доведением до конца своих игровых проектов. Этот список советов оказался для меня своего рода «зеркалом», в котором отражены многие проблемы, с которыми сталкивался я сам, и я был удивлен тем, насколько хорошо автору удалось уловить суть этих проблем и предложить свои решения, зачастую бескомпромисные.

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

Я всегда хотел попробовать себя в таком деле, как написание приложений для iPhone. Пусть для начала оно было простым, как «Hello world!», но зато написанное своими руками. Тем более платформа iPhone OS стала очень популярна, и большинство разработчиков отдают предпочтение именно ей. Но как говорится — мои желания не совпадают с моими возможностями. SDK доступен только для маков, а возможности купить мак у меня нет — дорогой. Но в интернете, случайно, узнал об одном сервисе о котором я расскажу далее.

In-App Purchases — это простой и удобный механизм для организации продаж своих приложений или дополнительных фич непосредственно из своего приложения. In-App Purchases легко встраивается и открывает для Вас новый канал продаж. Взаимодействие с App Store осуществляется с помощью StoreKit.framework, который поставляется вместе с SDK, начиная с версии 3.0.

Знакомо ли вам такое состояние, когда вы настолько увлечены идеей, что полностью погружаетесь в процесс ее реализации, забывая о времени и окружающем мире? А завершив, испытываете радость и даже счастье? Значит, у вас есть опыт потоковых состояний – особых ресурсных состояний сознания, когда все внимание сфокусировано на цели, и в результате замечательные идеи рождаются сами собой, и время концентрируется, вмещая гораздо больше, чем в обычном состоянии.
Тема эффективности потоковых состояний для работы и творчества уже несколько раз поднималась на Хабре, и в этой статье мы хотим обсудить практическую часть – что необходимо для того, чтобы вызывать это состояние «на заказ»?

Начать статью я хотел бы с констатации того факта, что прямо за окном находится 2011 год (пруфлинк), середина апреля. Напоминаю я это в первую очередь себе, поскольку меня периодически посещают в этом сомнения. Дело в том, что как по работе, так и ради хобби я часто читаю код на С++, написанный лет 10-20 назад (но поддерживаемый и поныне) или код написанный совсем недавно, но людьми, которые учились программировать на С++ те же 20 лет назад. И вот после этого у меня и возникает ощущение, что никакого прогресса за эти годы не было, ничего не менялось и не развивалось, а по Земле до сих пор бродят мамонты.

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

Все привыкли редактировать текст в текстовых редакторах, блокнотах, веб-формах и т.д. В процессе набора текста мы пользуемся привычными стрелками, кнопками «End» и «Home», более опытные зажимают «Ctrl» и стрелками шагают по словам (что, кстати, не всегда работает). И при переходе на консоль мы ориентируемся на те же самые правила, даже не зная, что bash предлагает очень удобные средства и комбинации клавиш, которые очень упрощают работу и минимизируют количество операций для выполнения задачи. К тому же, в bash есть удобные средства работы с историей, масса различных подстановок и других интересных функций. Самые часто используемые мной и любым опытным администратором я и опишу в этой статье.

Часто (в том числе и на хабре) всплывает вопрос освещения, особенно «нанотехнологиченого» светодиодного и зачастую говны священных войн «светодиод» против люминисцентных ламп начинают подбурливать. Больше года я уже собирался написать статью о свете, и оно наконец свершилось.
Из этой статьи вы узнаете почему в фотостудиях не снимают с люминесцентными лампами, почему светодиоды до сих пор не захватили мир и стоит ли ими освещать улицы. Поехали!

Давайте придумаем аналогию, а затем хорошенько над ней поиздеваемся: представьте, что вы только что приобрели земельный надел. Чем вы будете заниматься? Добычей ископаемых или фермерством?

Если будете заниматься фермерством, то нужно будет сначала приобрести семена, а потом весь сезон работать, чтобы получить прибыль. И каждый год вы будете закапывать (буквально) большую часть прибыли обратно в землю, зарплаты и выплаты по ипотеке. Вы будете разумно обращаться с почвой для того, чтобы она год за годом продолжала давать вам урожай. Если вы удачливы и все делаете правильно, то будете собирать урожай, продажи будут расти и, в конце концов, заработаете на приличную жизнь. Но каждый год, неважно насколько вы богаты, вы будете возвращаться к началу: гнуть спину, работая на земле. Когда вы наконец выйдете на пенсию, то, если вы все делали правильно, почва будет так же хороша как при покупке, и ваша ферма будет жить дальше.

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

Уже не помню, когда начились проблемы с производительностью при копировании файлов, но тогда я этому не придал большого значения так, как копировал файлы редко. Относительно недавно в моем распоряжении появилось высокоскоростное подключение к сети Интернет и теперь я часто копирую/качаю большие файлы и проблема падения производительности для меня стала очень актуальной.

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

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

Жизнь — дерьмовая штука. По крайней мере, так считают многие «взрослые» люди, с которыми мне довелось общаться. Они постоянно жалуются на свою работу, неудовлетворительные отношения и раздолбаев-детей, которые никак не хотят становиться такими, какими хотят их видеть родители. Жизнь для этих людей — это бесконечная карусель разочарований, неприятностей и несбывшихся надежд. Они встают рано утром с больной головой, заливают в рот пару литров кофе и едут на работу в состоянии, которому позавидовали бы самые отъявленные зомби. Они ненавидят свою работу и считают, что их занятия бессмысленны и никому не нужны. Но, не смотря на это, они с упорством леммингов продолжают делать эту работу, день за днём, год за годом. Они продираются сквозь собственную жизнь, надеясь, что всласть поживут потом, когда отработают 10-20-30 лет. Так вот, это всё херня. Когда вам будет пятьдесят, вы настолько устанете от такой жизни, что единственным вашим желанием будет лечь и сдохнуть. Да и здоровье будет уже не то, потому что вы слили его, занимаясь всякой ерундой, до которой вам даже не было дела. Так что, когда вы выйдете на пенсию, вы не поедете в Африку охотиться на львов, потому что солнце плохо сказывается на вашем давлении. Вы также не поедете на Северный полюс, потому что у вас артрит и холод — не лучшее для него лекарство. Южный полюс отпадает ещё и потому, что вы недолюбливаете пингвинов, что неудивительно, учитывая ваш 30-летний стаж работы сисадмином. Так что же вам остаётся? Поездки на дачу и вечера в уютной компании телевизора, вот что. Прожив 30 лет в постоянной борьбе с самим собой, у вас просто не останется сил на то, чтобы оторвать задницу от дивана.

С удивлением обнаружил, что про явление алиасинга (aliasing) здесь постов нет. Ситуацию нужно исправить, тк. алиасинг в любой сколько-то сложной C++ программе обязательно хоть где-нибудь, да есть. Это может быть хорошо, давая возможность ловких оптимизаций, а может быть плохо, внося повышенной паршивости баги. Под катом вкратце про оба случая (ну и неизменное «компилятор бьет спина», конечно; для разнообразия сегодня это gcc).

Обзор практически всех *top утилит под linux (atop, iotop, htop, foobartop и т.д.).

top

Все мы знаем top — самую простую и самую распространённую утилиту из этого списка. Показывает примерно то же, что утилита vmstat, плюс рейтинг процессов по потреблению памяти или процессора. Совсем ничего не знает про загрузку сети или дисков. Позволяет минимальный набор операций с процессом: renice, kill (в смысле отправки сигнала, убийство — частный случай). По имени top суффикс "-top" получили и все остальные подобные утилиты в этом обзоре.

atop

Atop имеет два режима работы — сбор статистики и наблюдение за системой в реальном времени. В режиме сбора статистики atop запускается как демон и раз в N времени (обычно 10 мин) скидывает состояние в двоичный журнал. Потом по этому журналу atop'ом же (ключ -r и имя лог-файла) можно бегать вперёд-назад кнопками T и t, наблюдая показания atop'а с усреднением за 10 минут в любой интересный момент времени.

В отличие от top отлично знает про существование блочных устройств и сетевых интерфейса, способен показывать их загрузку в процентах (на 10G, правда, процентов не получается, но хотя бы показывается количество мегабит).

Незаменимое средство для поиска источников лагов на сервере, так как сохраняет не только статистику загрузки системы, но и показатели каждого процесса — то есть «долистав» до нужного момента времени можно увидеть, кто этот счастливый момент с LA > 30 создал. И что именно было причиной — IO программ, своп (нехватка памяти), процесор или что-то ещё. Помимо большего количества информации ещё способен двумя цветами подсказывать, какие параметры выходят за разумные пределы.

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

Предупреждение: Эта статья вас ничему не научит. Это очень высокоуровневый взгляд, мои мысли, моя рефлексия на вопрос, который для меня важен + небольшое этнографическое исследование по графическим клиентам git-а.

Поговорим о распределенных системах управления версиями.

CVS был грустным, медленным, неатомарным („ничего не трогайте, я коммичусь“), зато с нормальным клиентом в Эклипсе.

SVN был медленным и поначалу веселым, но с появлением первой ветки тоже грустным („ничего не коммитьте, я мержусь“), с двумя разными клиентами в Эклипсе, баги которых нежно дополняли друг друга.

Тогда я выучил git. Git — это такой нелогичный набор утилит командной строки, в котором ежедневные операции выполняются последовательностью из двух–четырех команд.

В данной статье рассматривается реализация multiseat на базе Ubuntu 10.04 LTS с аппаратным ускорением. Пример, рассмотренный в этой статье, уже введен в эксплуатацию и работает около полугода в обычном Минском офисе. Описываются проблемы реализации и внедрения готовой системы в работу с точки зрения обычного студента-электроприводчика, который подрабатывает на полставки системным администратором.

Вступление

Вот время работы системным администратором в небольшом офисе при обновлении парка компьютеров появилась небольшая проблема. Современные компьютеры дают уровень производительности, много превосходящий необходимый для офисных компьютеров. Причем реалии рынка таковы, что различия в производительности мало сказываются на цене. И вроде бы дешевые компьютеры на базе Atom по ценовому признаку практически не отличаются от более производительных компьютеров на базе обычных процессоров Amd и Intel (материнская плата с процессором Atom стоит около 100-150 у.е. на май 2010 года, Минск, и та же цена на октябрь 2010 в том же Минске).

Та же ситуация и с жесткими дисками: для офисной работы нет необходимости в объеме диска более 40-80 Гб. Но на рынке такие жесткие диски уже практически не представлены. На момент написания статьи в продаже были жесткие диски емкостью 160 Гб (38$), 250 Гб (39$), 320 Гб (40$), 500 Гб (41$), дальше различия по ценам заметны сильнее. Цена за гигабайт жестких дисков малого объема довольно высока. Та же ситуация и со всеми остальными комплектующими.

Возникает закономерный вопрос, как рационально все это использовать? Давайте подойдем логически — чтобы удешевить систему можно либо купить комплектующие похуже (не сильно удешевляет), либо отказаться от некоторых комплектующих. По сути, в рабочем месте обязательными являются устройства ввода (клавиатура, мышь, планшет и т.д.) и устройства отображения информации (монитор, проектор и т.д.). Остальная часть системы пользователей особо не касается, и от нее можно избавляться. Безусловно, от всего избавиться не получится. Давайте заглянем под крышку системного блока. Тут мы обязательно видим материнскую плату, видеокарту (может быть уже на материнской плате), процессор (тоже может быть на материнской плате) и память. А вот остальные комплектующие уже не так важны. Оптический привод мало востребован, и поэтому его, скорее всего, не будет.
С жестким диском тоже интересная ситуация. Его может и не быть, тогда у нас будет так называемая бездисковая станция. Тут вся информация загружается по сети с сервера (реализация PXE+NFS и немного бубна). Но хочется чего-то большего.
Тогда и возникла идея подключить к одному компьютеру две клавиатуры, две мыши и два монитора и заставить их работать независимо. В зарубежных источниках такие системы называются multiseat.
Но можно на этом и не ограничиваться, а делать бездисковую multiseat-станцию. Этот вариант отлично подойдет для пары multiseat-станций с сервером. В данной статье не рассматривается.