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

Эпиграф: Зарплата у меня хорошая, но маленькая!

Глядя на то, как появляются и исчезают в черновики вместе с комментариями и обсуждениями статьи о найме и удержании сотрудников, я тоже решил рискнуть.
Я хочу поспорить с тезисом о том, что деньги не мотивируют и высказать свои аргументы в пользу высокой заплаты.
Вот тезисы, которые я хочу раскрыть немного подробнее в статье.
1. Высокая зарплата не мотивирует. А вот низкая зарплата демотивирует сама по себе.
2. Высокая зарплата отрезвляет, так как хорошо понимаешь, что на такую позицию быстро найдутся желающие.
3. Высокая зарплата затрудняет переход в другое место.

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

Эрик Липперт — ветеран Microsoft, проработавший в компании 16 лет и стоящий за разработкой VBScript, JScript и C#.

На прошлой неделе в комментариях к одной из статей разгорелся спор о роли низкоуровневой оптимизации в программировании, и я вспомнил относящуюся к этому статью Эрика. Она была написана в конце 2003, и хотя реалии с тех пор несколько изменились — принципы остались теми же самыми. Можете мысленно заменить ASP и VBScript на PHP, JavaScript, или на другой скриптовый язык по вашему вкусу.

Эту статью я уже пытался перевести в 2005, но русский текст тогда получился неуклюжий, так что этот перевод — новый и ранее не публиковался, в соответствии с требованиями НЛО. В Переводе блога Эрика Липперта этого текста тоже нет — наверное, для них он слишком стар.

---

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

Например, за семь лет в Microsoft я получил десятки вопросов, аналогичных по своей сути этому, заданному в конце 1990-х:

У нас есть код на VBScript, и в одной часто вызываемой функции мы определяем оператором Dim несколько переменных, которые нигде в функции не используются. Не замедляется ли каждый вызов функции из-за объявления этих переменных?

Какой интересный вопрос! В компилируемом языке, таком как Си, объявление локальных переменных общим размером n байт всего лишь вычитает n из указателя стека при входе в функцию. Если n будет чуть больше или чуть меньше, затраты времени на вычитание никак не изменятся. Наверное, в VBScript точно так же? Оказалось, что нет! Вот что я написал автору вопроса:

Администраторам Linux писать скрипты на Bash приходится регулярно. Ниже я привожу советы, как можно ускорить эту работу, а также повысить надежность скриптов.

Совет 1

Не пишите скриптов, которые выполняют действия ничего не спрашивая. Такие скрипты нужны довольно редко. А вот всевозможного «добра» для копирования, синхронизации, запуска чего-либо, хоть отбавляй. И если в любимом Midnight Commander Вы вдруг нажали не на тот скрипт, то с системой может произойти все что угодно. Это как правила дорожного движения — «написано кровью».

Совет 2

Отталкиваясь от предыдущего, в начало каждого скрипта неплохо помещать что-то вроде:

read -n 1 -p "Ты уверен, что хочешь запустить это (y/[a]): " AMSURE 
[ "$AMSURE" = "y" ] || exit
echo "" 1>&2

Команда echo, кстати, здесь нужна потому, что после нажатия кнопки <y> у вас не будет перевода строки, следовательно, следующий любой вывод пойдет в эту же строку.

Совет 3

Это ключевой совет из всех. Для того, чтобы не писать каждый раз одно и то же — пользуйтесь библиотеками функций. Прочитав много статей по Bash, я вынужден констатировать, что этой теме уделяется мало внимания. Возможно в силу очевидности. Однако я считаю необходимым напомнить об этом. Итак.
Заведите свою библиотеку функций, например myfunc.sh и положите ее, например в /usr/bin. При написании скриптов она не только поможет сократить ваш труд, но и позволит одним махом доработать множество скриптов, если Вы улучшите какую-либо функцию.
Например, в свете совета 2 можно написать такую функцию:

В мире информации необходимы как эффективные методы обмена ей, так и способы ее хранения. В каждой современной системе используется несколько различных СУБД, каждая из которых обладает своими достоинствами и была выбрана для удовлетворения определенных нужд. Однако, разнообразие в форматах порождает проблему совместимости и совместной работы с ресурсами. Чтобы решить проблему дублирования данных и несовместимости форматов, был начат проект Akonadi — четвертый из рассмотренных нами столпов KDE4.

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

Наш коллега Егор Куликов стал победителем самого престижного международного личного первенства среди программистов – TopCoder Open 2012!

Егор работает в петербургском офисе Яндекса, в отделе разработки мобильных продуктов. В прошлом Егор – победитель и призер многочисленных школьных олимпиад по математике, бронзовый медалист чемпионата мира по программированию среди студенческих команд, а в 2010 году он завоевал первое место в другом крупном соревновании – Google Code Jam.

Таким образом, Егор стал вторым россиянином, после Петра Митричева, выигравшим и TopCoder Open, и Google Code Jam.

Я работаю программистом уже много лет, на протяжении которых, как это ни странно, я всё время что-то программирую. И вот какую интересную вещь я заметил: в коде, написанном мной месяц назад, всегда хочется что-то чуть-чуть поправить. В код полугодичной давности хочется поменять очень многое, а код, написанный два-три года назад, превращает меня в эмо: хочется заплакать и умереть. В этой статье я опишу два подхода. Благодаря первому архитектура программы получается запутанной, а сопровождение — неоправданно дорогим, а второй — это принцип KISS.

Итак, представим себе, что есть два программиста. Один из них умный, прочёл кучу статей на Хабре, знает каталог GoF наизусть, а Фаулера — в лицо. Другой же делает всё просто. Первого будут звать, например, Борис Н., а второго — Маркус П. Само собой, имена вымышленные, и все совпадения с реальными людьми и программистами случайны.

Итак, к ним обоим приходит проектный менеджер (если в вашей вселенной PM не ходит сам к программистам, назовите его как-то иначе, например BA или lead, сути это не изменит) и говорит:
— Ребята, нам нужно, чтобы делался хлеб.

Именно так, «делался», без уточнения способа производства.

Как же поступят наши программисты?

Яндекс знает. Телеканал Россия 24 знает. Даже на Первом канале информация имеется. А мы тут сидим и молчим всем бложиком!
Каждый из участников IOI 2012 от России привёз по золотой медали!

Если кто не в курсе, то IOI – это один из самых престижных в мире ежегодных конкурсов по программированию, который проходит под патронатом UNESCO и IFIP. На соревновании команды из разных стран мира, состоящие из четырех участников, на протяжении двух дней решают алгоритмические задачи.

Россию на олимпиаде этого года представляли Максим Ахмедов и Олег Иванов из Москвы, Егор Суворов из Санкт-Петербурга и Алексей Гордеев из Перми. Все они являются победителями Всероссийской олимпиады школьников по информатике этого года. Их сопровождали бессменные руководители нашей сборной Кирюхин Владимир Михайлович и Цветкова Марина Серафимовна.

Для интересующихся не составит труда найти информацию о заданиях (для этого есть официальный сайт), ходе олимпиады (тут, например), да и вообще почти о любых аспектах меропрятия (пресс-релиз SnarkNews, таблица командного зачёта, да и вообще что угодно — поисковик в помощь :)). Я же под катом постараюсь хоть чуть-чуть рассказать о самих победителях, а точнее, дать представление о том, сколько всего разного было на их пути к этой олимпиаде.

Введение

Грамотно налаженные и состоявшиеся процессы — не для нас! Это ведь скучно, когда все уже настроено и работает как часы, но к этому надо стремиться. А уж после порадоваться проделанной работе и очередной раз проверить, как же все хорошо работает…

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

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

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

С потерей данных я впервые столкнулся, когда лишился своей коллекции тщательно отредактированных переводов любимой книги во время банальной переустановки ОС. Это было очень давно, однако воспоминания о часах кропотливого труда, потраченного на доведение до ума нескольких миллионов знаков текста до сих пор не дают мне покоя. Тогда ещё не было различных облачных технологий типа дропбокса, поэтому потеря оказалась практически невосполнимой. Конечно, не всё и не всегда так трагично – если сам носитель всё ещё есть в наличии, потерянные данные можно восстановить. Эх, знал бы, где упаду…

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

Дорогие мои, любимые, сохабровцы! Должен признаться вам, что я, на правах религиозного фанатика, являюсь совершенно счастливым человеком, но последних лет 16, из своих 32, наблюдаю вокруг все усугубляющуюся картину борьбы общества с абсурдностью бытия. Дело в том, что многие из моих знакомых работают в крупных компаниях, где их безжалостно гнобит офисная сансара, а у меня, уж так сложилось, никогда не было жесткого графика и довлеющей корпоративной машины за спиной, за что я денно и нощно возношу хвалу Аллаху. Находясь на значительном удалении от этих проблем и будучи в них эмоционально не вовлеченным, занимаясь наукой в свое удовольствие в НИИ Системных технологий (а на жизнь зарабатывая собственным ИТ-бизнесом), при помощи чудодейственного системного анализа я постараюсь обобщить тут все, что знаю по теме.

Данный пост представляет собой выдержку «золотых правил» из примечательной книги Питера Гудлифа «Ремесло программиста».

Кто-то освежит память, кто-то сверится как с чек-листом, а кто-то заинтересуется и прочтет книгу. Т.к. пост получился достаточно объемным, можно добавить его в закладки и периодически к нему возвращаться.