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

Я думаю, всем из нас известна данная система компьютерной алгебры. Она не является конкурентом Wolfram Mathematica, но она обладает именно тем функционалом, который я требую от математического софта. Если говорить проще и доступнее — считать можно на всём, от палочек до суперкомпьютеров, и далеко не всегда задачи инженерной практики целиком переносятся с бумаги в программный код. Одним из примеров, который я честно говоря, еле-еле застал, является сегодня забытая поделка нашего конверсионного производства — цельнометаллический бытовой вакуумный гражданский термос, который выпускался ранее ещё в СССР на Урале. Чтобы наладить его производство институт, в котором я учусь, де-факто вручную на счётных машинках высчитал все необходимые параметры рабочего оборудования. Поэтому лицензия на Mathematica — не показатель и не ценз пригодности к практике. Считать, повторюсь, можно на всём.

От слов к делу. Ниже разбиты на категории те моменты в документации Maxima, которые желательно знать для начинающего пользователя данной СКА.

Это руководство — начальный материал о кросс-DPI и кроссплатформенном дизайне для начинающих и средних дизайнеров, желающих узнать о нем с самого начала или получить больше знаний. Без сложных математических и непонятных диаграмм, только непосредственные объяснения, упорядоченные в небольших разделах, для понимания и применения их непосредственно к вашей дизайнерской работе.

Автор — Sebastien Gabriel.

Я не знаю всего, так что, если по вашему мнению я где то ошибаюсь или вам нужно уточнить что-то, либо у вас есть предложения или вопросы для улучшения данного руководства, отправьте письмо (на англ) на sgabriel.contact@gmail.com. Вы также можете найти на меня Twitter, G+ или Facebook.

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

Помните пост «Что хабровчане носят с собой», где народ хвастался содержимым своего рюкзака? Меня, если честно, больше интересовало не содержимое, а то, в чем народ носит свои вещи. Вот так, к слову, выглядела одна из наиболее интересных вещей — фотосумка Boomburum.



Сегодня мне бы хотелось зайти к той теме с другой стороны и показать десяток отличных (действительно отличных) сумок на разный вкус, цвет и кошелек.

И начать делать полезную документацию

Подавляющее большинство проектов по построению ИТ-инфраструктуры, реализованных даже очень крупными системными интеграторами, обладает одним существенным недостатком – бесполезной проектной документацией. Нет, нет, конечно же, документация содержит все необходимые данные и, прочитав ее можно разобраться, что и как было организовано. Бесполезность ее проявляется при дальнейшей эксплуатации информационных систем и выражается в сложности поддержания документации в актуальном состоянии и невозможности оперативно найти в ней нужную информацию. Как следствие, данная проектная документация, со временем, вместо полезного справочного материала становится еще одним красивым и бесполезным отчетным документом.

В данной статье я бы хотел поделиться с моими коллегами некоторыми принципами составления проектной документации, которые мы используем в своей работе и которые, возможно, позволят вашим клиентам наслаждаться не только качественно построенной вами ИТ-инфраструктурой, но и легко и непринуждённо поддерживать в актуальном виде документацию по ней, годами вспоминая вас добрым словом. Приступим:

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

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

В общем стоимость услуг фрилансера должна быть основана на трех факторах:

1. Собственные потребности
2. Стоимость услуг конкурентов
3. Потребности рынка

В наше время в сети достаточно легко найти «12 правил фрилансера», или «20 советов фрилансеру», а то и «библию фриланса».
У всех разное отношение к этому явлению, разный опыт или предубеждения. Немало, кстати, негативных мнений.
Мне бы не хотелось писать очередное руководство «как заработать 10000$ в месяц». Поделюсь своим небольшим, но положительным опытом в роли «Фрилансера» и кое-какими выводами. Этот опыт сделал для меня работу на фрилансе комфортной и прибыльной.

Популярному почтовому сервису от Google не удалось избежать повторения ситуации с выкладыванием довольно внушительных баз с логинами и паролями, которая недавно случилась с Yandex и Mail.ru. В сети появилась база с адресами ящиков и паролями на 4929090 аккаунтов gmail.com. Актуальность базы не проверена, но сообщается о более чем 60% валидных пар почта: пароль.

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

Предыстория: я веду свой паблик ВК о веб-разработке, в связи с чем я каждый день имею дело с большим количеством материалов о веб-разработке. Однажды (3 месяца назад) мне пришла в голову идея опубликовать на хабре подборку «30 полезных сервисов для веб-разработчика». Тот пост набрал почти 100 000 просмотров, и мне приятно, что он оказался полезен сообществу. С тех пор у меня поднакопилось больше 30 новых сервисов, которые будут полезны как разработчикам, так и дизайнерам. Лучшие из них я собрал в этом посте. Осторожно, под катом много картинок!

Решил собрать сервисы, которые могут быть полезны веб-разработчикам и дизайнерам. Буду рад, если кто-то найдет для себя полезный сервис. Осторожно, под катом куча картинок!

На этой неделе интернет был потрясен историей, связанной с утечкой сотен интимных фотографий знаменитостей (статьи на Хабре на связанную с этим тему здесь и здесь). Одно из самых тщательных расследований этой истории провел рожденный в Австралии предприниматель, блогер, инженер и разработчик софта (все это в одном лице) Ник Кубрилович (Nic Cubrilovic). Ник известен тем, что в разные периоды своей карьеры был журналистом и консультантом Techcrunch и Crunchpad, редактором TechcrunchIT, основателем или со-основателем Omnidrive, Solutionstap, MyVirtualDrive, Webwall, 2web и прочее. Подробности – под катом.

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

Однако, похоже, что беды пользователей почтовых систем на этом не закончились — в сеть попала база email адресов с паролями от почтового сервиса mail.ru. В этой базе содержатся 4 664 478 записей. Актуальность базы не проверена, но, учитывая ситуацию с аккаунтами почты Яндекса, такое продолжение истории не кажется невероятным.

Сегодня на одном довольно широко известном ресурсе разместили базу email адресов с паролями от почтовых ящиков «Яндекса». База представляет собой текстовый документ, в котором заявлено 1 млн позиций.

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

Когда именно, и по какой причине данная база утекла в сеть, остается неизвестным. В комментариях народ пишет, что из первых попавшихся 10 яшиков как минимум 8 являются на настоящий момент валидными.

В общем, дружно меняем пароли, пока представители «Яндекса» ищут крота.

Вот уже полтора года я зарабатываю фрилансом на бирже oDesk. За это время у меня накопилось много материалов по данной теме. В данном топике я собрал все в одну статью и адаптировал для аудитории хабра.

Во время написания статьи пришел к выводу, что объяснить всю техническую часть по данной теме в одном посте практически невозможно, а может и никому не надо. Поэтому решил сделать данный пост обзорным над моей работой. Цель поста — показать, как не используя дополнительное финансирование компании и выпросив пару виртуальных серверов можно построить эффективную среду мониторинга активного оборудования большой сети в крупной компании.

Если вас интересует тема мониторинга сети или есть желание сравнить мою работу с имеющейся у вас, приглашаю под кат.

Данные правила, как говорится, «написаны кровью». Возможно, кому-то они помогут сохранить немного (много) жизни и нервов.

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

Приходя на новое место работы, каждому системному администратору хочется получить пакет исчерпывающей технической документации. И первые по важности в этом пакете документы об устройстве сети и серверов.

Искусство организации рабочего времени (time-management) последнее время обретает всё большую популярность и если раньше это в основном относилось к менеджерам различного уровня, то теперь накопленные знания начинают применяться и в других областях деятельности компании.

Существует много пособий по настройке программ (Операционок, сервисов, сайтов и тд), но редко можно встретить мануал по организационным вопросам связанным с системным администрированием. Сразу скажу, опыт работы у меня достаточный. Рассматриваться предмет будет на моем личном примере работы, сразу скажу что любые аргументированные дополнения, и исправления приветствуются. Также поясню для господ минусующих: «Не нравится? Сделай лучше!», и обязательно пришли ссылку, почитаю с большим удовольствием.

Введение

Эта статья – скорее из разряда «для самых маленьких», чем «для умудренных опытом», но она призвана повышать профессиональную культуру системных администраторов.
В силу специфики работы мне «по наследству» достается самый разнообразный облачный ад, который приходится разгребать, оптимизировать, приводить в чувство и делать прозрачным и красивым. Эти заметки, пожалуй, иллюстрация к тем моментам, которые вообще недопустимы в системном администрировании.
В причинах, которыми порождаются эти анти-паттерны, можно разбираться очень долго: дедлайны, законы и темпы бизнеса, да и просто идиотизм, наконец. Но цель статьи другая. Мне бы хотелось породить конструктивную дискуссию. А вот уже её результаты и являются основной целью статьи.

Эта заметка навеяна мелькавшими последнее время на хабре постами двух тематик — «интересные команды unix» и «как я подбирал программиста». И описываемые там команды, конечно, местами интересные, но редко практически полезные, а выясняется, что реально полезным инструментарием мы пользоваться и не умеем.
Небольшое лирическое отступление:
Года три назад меня попросили провести собеседование с претендентами на должность unix-сисадмина. На двух крупнейших на тот момент фриланс-биржах на вакансию откликнулись восемь претендентов, двое из которых входили в ТОП-5 рейтинга этих бирж. Я никогда не требую от админов знания наизусть конфигов и считаю, что нужный софт всегда освоится, если есть желание читать, логика в действиях и умение правильно пользоваться инструментарием системы. Посему для начала претендентам были даны две задачки, примерно такого плана:
— поместить задание в крон, которое будет выполняться в каждый чётный час и в 3 часа;
— распечатать из файла /var/run/dmesg.boot информацию о процессоре.

К моему удивлению никто из претендентов с обоими вопросами не справился. Двое, в принципе, не знали о существовании grep.



Поэтому… Лето… Пятница… Перед шашлыками немного поговорим о grep.