Обзор практически всех *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 программ, своп (нехватка памяти), процесор или что-то ещё. Помимо большего количества информации ещё способен двумя цветами подсказывать, какие параметры выходят за разумные пределы.

Недавно на хабре прочел про списки can-do (в качестве усовершенствованной версии списков to-do). Мне понравилась мысль, что «надо» — это очень паршивая мотивация, поскольку на себе знаю что оная или превратит меня в робота или в лентяя, протестующего против любого навязывания. Но и эти списки все еще несвободны от негативной мотивации. Глядя на формулировку списка can-do меня не покидает ощущение, что это те же самые горькие пилюли «надо» только в растворимой сладковатой оболочке. Во-первых, тут есть смысловое размытие: «могу» означает как способности (can) так и вероятность (may), а нечеткий смысл вызывает подозрение что я сам себя пытаюсь где-то обхитрить. Во-вторых, постановка себе целей с формулировкой «могу» напоминает игру «Слабо?», т.е. предполагает что я стиснув зубы добьюсь этого результата только чтоб доказать себе что я смог: цель ради цели, преодоление ради преодоления, работа без учета соображения, а нафига я вообще это делаю. И в конце дня глядя на невычеркнутые «могу», я чувствую неприятный осадок и неверие в свои способности, что станет толчком к тому чтоб отказаться и от таких списков.

Танцуют все!

Итак, только что завершили формирование образов и окончательно вышел Debian GNU 6.0 «Squeeze», как обычно доступно множество архитектур, среди которых:

• amd64
• armel
• kfreebsd-i386
• kfreebsd-amd64
• i386
• ia64
• mips
• mipsel
• powerpc
• sparc
• s390

Почему команды жгут? Почему одни команды полны энтузиазма, доверия и страсти, а другие аппатичны и скучны? К сожалению, не существует рецепта создания классной команды. Невозможно добавить 5 граммов доверия, поджечь, добавить немного общения и варить до готовности.

А нужны ли нам вообще команды?

Работа в одиночку

Работать в одиночку очень круто. Вам не нужно доверие. Вы же доверяете самому себе по умолчанию? Если нет, то вам без всякого сомнения нужна квалифицированная медицинская помощь. Также вам не нужны навыки общения. Конечно, вы можете разговаривать сами с собой, но если это происходит слишком часто, вам также нужна медицинская помощь. Все, что вам нужно для эффективной работы — это навыки решения проблем, технические знания и страсть. Однако, этого недостаточно для эффективной работы команды.

Если вы работаете в одиночку, вы принимаете любые решения быстро. Не надо ни с кем спорить и что-то кому-то доказывать. Решили как это сделать, и вперед! У вас минимальная дополнительная нагрузка на рабочий процесс: нет совещаний, нет обсуждений, нет телефонных звонков, нет идиотских вопросов со стороны недалеких коллег.

При работе в команде все не так радужно, не так ли? Внезапно, вам приходится посещать совещания. Вам приходится участвовать в различных дискуссиях на технические темы (что еще ничего), а также на другие неинтересные и скучные темы. Вам приходится отвечать на вопросы, хотя бы из вежливости, а также частенько делать вещи, с которыми вы совершенно несогласны.

Так зачем же люди формируют команды?

Примечание переводчика: хоть статья довольно старая (опубликована 2 года назад) и носит громкое название, в ней все же дается хорошее представление о различиях реляционных БД и NoSQL БД, их преимуществах и недостатках, а также приводится краткий обзор нереляционных хранилищ.

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

Если это правда, значит ли это, что могучие реляционные БД стали уязвимы? Значит ли это, что дни реляционных БД проходят и скоро совсем пройдут? В этой статье мы рассмотрим популярное течение нереляционных баз данных применительно к различным ситуациям и посмотрим, повлияет ли это на будущее реляционных БД.

Доброго времени суток!

В этом посте я хотел бы поделиться опытом разработки приложения и не очевидного способа монетизации.

История началась год назад. Заболев на новогодние праздники, я решил не тратить время зря, а начать изучение платформы Android. На тот момент про нее я знал немного, да и в Java был не силен. Изучение решил начать с написания небольшой игры.

UPD: А кто-нибудь может прокомментировать цену? Много это или мало, сколько Вам кажется оно могло стоить?

О чём эта статья

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

В этой статье я напишу как устроен алгоритм шифрования AES (которого иногда называют Rijndael) и напишу его на JavaScript. Почему на JavaScript? Чтобы запустить программу на этом языке, нужен только браузер в котором вы читаете эту статью. Чтобы запустить программу, скажем, на C, нужен компилятор и найдётся совсем мало желающих, готовых потратить время на компиляцию кода из какой то статьи. В конце есть ссылка по которой можно скачать архив с html страницей и несколькими js файлами — это пример реализации AES на JavaScript.

Часть хабралюдей честные и бескорыстные и привлекают их всякие техническия штучкэ. Но кое-кто кое-где у нас порой и не столь бескорыстен. Честно жить не хочет. Я расскажу вам о том, как можно по сути воровать, но при этом не выходя за рамки уголовного кодекса. Эдак с $15,000,000.

Ежедневно я работаю за компьютером 9–10 часов. Вплоть до прошлой недели я проводил все это время, сидя на своей вечно расширяющейся заднице.

В понедельник я отрегулировал свой стол для стоячего положения (фотография выше) и провел неделю, работая исключительно стоя. К сидению я теперь никогда не вернусь.

Думаю многие фрилансеры и не только, задавались этим вопросом. Сначала написал целый абзац текста, а потом подумал зачем лить воду? В общем вот конкретика:

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

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

Интересно, что в далеком 1998 году читатели журнала «Software Development» признали Стива одним из трех наиболее влиятельных людей в отрасли разработки ПО наряду с Биллом Гейтсом и Линусом Торвальдсом.

Если говорить коротко, то Steven C. McConnell — программист и автор книг по разработке ПО.

Он написал книги «Rapid Development» (1996), «Software Project Survival Guide» (1998), «Professional Software Development» (2004). Журнал «Software Development», кстати, дважды удостоил его книги премии Jolt Excellence как лучшие книги года о разработке ПО.

Кстати, вы наверняка слышали фразу «Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете». Так вот, эту фразу приписывают именно Стиву.