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



В повседневной работе в Linux / Unix мы используем множество инструментов командной строки — например, du для мониторинга использования диска и системных ресурсов. Некоторые из этих инструментов существуют уже давно. Например, top появился в 1984 году, а первый релиз du датируется 1971 годом.

За прошедшие годы эти инструменты были модернизированы и портированы на разные системы, но в целом далеко не ушли от своих первых версий, их внешний вид и usability также сильно не изменились.

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

Я делаю много ревью для чужого кода на Ансибл и много пишу сам. В ходе анализа ошибок (как чужих, так и своих), а так же некоторого количества собеседований, я понял основную ошибку, которую допускают пользователи Ансибла — они лезут в сложное, не освоив базового.

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

Ожидаемый уровень читателя — уже написано несколько тысяч строк ямла, уже что-то в продакшене, но "как-то всё криво".

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

Я достаточно часто сталкивался с подобным мнением и не придавал ему особого значения, но когда женский коллектив нашей организации поздравил программистов с 23-м февраля по доброму назвав их «космическими войсками», решил всё же расставить определенные акценты в данном вопросе, т.к. одна из моих профессий связана напрямую с психоанализом. Да и баш уже не молчит.

Этот пост понравится мизантропам: ведь он про то, что нет ничего бесполезнее, чем чужой успех. Вот если бы было место, где люди честно бы делились своими планами, а потом можно было бы следить поэтапно за их реализацией и фиксировать не только удачи, но и провалы в итоге… Ой, я же пишу в блоге такого проекта. Заходим на «СмартПрогресс», выбираем меню Цели, сортировку «проваленные», добавляем параметр «лучшие за все время» — и смотрим список самых громких фейлов на проекте.



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

Что такое хороший язык программирования? Какими качествами и характеристиками он должен обладать? Ответ дать сложно. Вот одно из возможных определений: хороший ЯП должен хорошо решать возложенные на него задачи. Ведь ЯП — лишь инструмент в руках программиста. А инструмент обязан помогать нам в работе. В конце концов, это же и есть причина его создания. Разные ЯП стараются решать разные проблемы (с переменным успехом). Цель, которая ставилась при проектировании Clojure — сделать написанные нами программы простыми. И, как следствие, ускорить их создание, тестирование. А главное, уменьшить время на их понимание, изменение и сопровождение.

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

Подобные средства есть для всех распространенных настольных ОС, включая Linux и BSD, и многие из них совершенно бесплатны, так что вряд ли имеет смысл ограничивать себя в Блокнотом Windows, nano или cat.

Однако, в среде поклонников Unix гуляет в разнообразных вариациях мем о том, что «Unix — это IDE», в том смысле, что средства, которыми разработчики располагают в терминале, легко реализуют основные возможности современных IDE. Вы можете соглашаться или отказываться признать Unix «IDE» в том самом смысле, что Eclipse или Microsoft Visual Studio. Так или иначе, вас скорее всего удивит, насколько законченную среду разработки может являть собой скромный Bash.

19 мая в офисе JetBrains прошла наша вторая встреча Scala-разработчиков в Санкт-Петербурге — ScalaDev.



Под катом вас ждут видео и презентации докладов:

— «scala.reflect», Евгений Бурмако (EPFL)
— «Курс молодого подрывника», Василий Ременюк (Viaden)
— «Магия Scala изнутри», Александр Подхалюзин (JetBrains)
— «Язык Kotlin», Светлана Исакова (JetBrains)

В первый раз я услышал о CQRS, когда устроился на новую работу. В компании, в которой работаю и по сей день, мне сразу сказали что на проекте, над которым я буду работать используется CQRS, Event Sourcing, и MongoDB в качестве базы данных. Из этого всего я слышал только о MongoDB. Попытавшись вникнуть в CQRS, я не сразу понял все тонкости данного подхода, но почему-то мне понравилась идея разделения модели взаимодействия с данными на две — read и write. Возможно потому что она как-то перекликалась с парадигмой программирования “разделение обязанностей”, возможно потому что была очень в духе DDD.

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

Сразу хочу уточнить что я работал только со связкой CQRS + Event Sourcing, и никогда не пробовал просто CQRS, так как мне кажется что без Event Sourcing он теряет очень много бенефитов. В качестве CQRS фреймворка я буду использовать наш корпоративный Paralect.Domain. Он чем-то лучше других, чем то хуже. В любом случае советую вам ознакомиться и с остальными. Я здесь упомяну только несколько фреймворков для .NET. Наиболее популярные это NCQRS, Lokad CQRS, SimpleCQRS. Так же можете посмотреть на Event Store Джонатана Оливера с поддержкой огромного количества различных баз данных.

Начнем с CQRS

Что же такое CQRS?
CQRS расшифровывается как Command Query Responsibility Segregation (разделение ответственности на команды и запросы). Это паттерн проектирования, о котором я впервые услышал от Грега Янга (Greg Young). В его основе лежит простое понятие, что вы можете использовать разные модели для обновления и чтения информации. Однако это простое понятие ведет к серьёзным последствиям в проектировании информационных систем. (с) Мартин Фаулер

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

1. Я прав, а ты нет

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

Мнение переводчика может иногда не совпадать с мнением автора, но переводить статью было крайне занимательно.

UPD: альтернативный вариант перевода вы можете найти на rsdn (спасибо flamingo за ссылку).

Это перевод статьи, датированной 1м сентября 2009 года, следует это учесть при прочтении. — прим. пер.

В последний месяц или два команда инженеров Digg потратила совсем немного времени на изучение, тестирование и окончательное внедрение Cassandra в продакшен. Это был очень веcёлый проект, но до того, как веселье началось, нам пришлось потратить какое-то время на выяснение того, что же представляет собой модель данных Cassandra… фраза «WTF is a «super column»» («что за фигня этот суперстолбец?») была произнесена не один раз.

Если вы работали ранее с РСУБД (это касается почти всех), вы вероятно будете немного обескуражены некоторыми названиями при изучении модели данных Cassandra. Мне и моей команде в Digg потребовалось несколько дней обсуждений, прежде чем мы «врубились». Пару недель назад в списке рассылки разработчиков шёл процесс bikeshed-а на тему полностью новой схемы именования для разрешения неразберихи. На всём протяжении дискуссии я думал: «может, если будет несколько нормальных примеров, люди не будут так смущены названиями». Так, это моя попытка объяснения модели данных Cassandra; она предназначена для того, чтобы вы ознакомились, но не уходили в дебри, и, надеюсь, это поможет прояснить некоторые вещи.

Не так давно промелькнула ссылка на достаточно свежее (осень 2011) англоязычное голосование со скромным названием "самая впечатляющая книга, которую должен прочесть каждый разработчик программного обеспечения" и описанием:

Если бы вы могли вернуться в прошлое, к самому началу своей карьеры разработчика и сказать самому себе: «прочитай именно эту книгу», в самой начале своей карьеры разработчика, какую бы книгу вы рекомендовали?

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

Однако в данном небольшом посте я возьму на себя смелость перечислить ТОП-5 тех самых книг, победивших в голосовании, переведенных на русский язык. И дать небольшие комментарии, ведь книги действительно этого достойны. Да, лично я бы поменял некоторые места, однако положимся на «мнение зала» ресурса Stack Overflow.

Предположим, у вас есть большое приложение написанное на Java. Это может быть web-сервлет размещенный в контейнере или standalone-сервис. В процессе разработки (да и во время эксплуатации) возникает необходимость отслеживать процессы, протекающие в JVM: работу garbage collector, использование памяти, жизненный цикл потоков, а так же иные специфичные для вашего проекта показатели посредством MBean. Самый простой вариант — использовать профилировщик. Но увы, проблемы не случаются по расписанию, и невозможно заранее знать, когда нужно подключить профилировщик, а держать его постоянно включенным тоже не вариант. В таких случаях идеальное решение — непрерывный мониторинг. О нем и пойдет речь. Но для начала пара слов о классической профилировке.

Введение

Доброго времени суток! Сразу оговорюсь, что цель этой статьи — познакомить и, возможно, заинтересовать вас такой штукой, как мнемоника. Мнемоника — наука о запоминании. То бишь совокупность способов и уловок, которые помогут вам запомнить большие объёмы информации в правильной последовательности (Например, 100 случайных слов (чисел) можно запомнить последовательно с интервалом в среднем в 6 секунд). Некоторые умудряются запомнить несколько тысяч цифр после числа Пи. Так же мнемотехника помогает в освоении иностранного языка ). Но нам пока рано об этом думать. Вы спросите:«Зачем мне ета ваша мнемоника?». Я отвечу: вы можете использовать её не только как хобби (от простого облегчения жизни, до того, что можете удивлять друзей, предложив с ними поочерёдно запомнить N информации поочерёдно), но и участвовать в соревнованиях (да-да, есть соревнования по запоминанию, где участвуют не прирождённые гении, а люди, натренировавшие себе память).

На данный момент времени, есть следующие альтернативы github:

• Сам github fi (стоит 5000$, не open source)
• Gitorious (open source, написан на RoR, использует ActiveMQ, короче — зверь машина)
• Недавно появившийся gitlab (open source, написан на ruby)

В этот список я хотел бы добавить мое приложение. Может быть, оно еще кому то пригодится. Что у него внутри:

В начале текущего учебного года Stanford организовал 3 бесплатных онлайн курса (основаные на трёх стационарных курсах Стэнфорда): Machine learning, Artificial intelligence и Introduction to Database. Все курсы идут с видео лекциями и домашними заданиями. Для курсов Artificial intelligence и Introduction to Database предусмотрены ещё и экзамены. После успешного окончания любого из курсов будет выслан сертификат (digital-signed pdf) от преподавателя.

И вот, были анонсированы ещё несколько онлайн курсов, которые будут стартовать в январе/феврале 2012 года.

• Computer Science by Nick Parlante
• Natural Language Processing by Dan Jurafsky and Chris Manning
• Software Engineering for SAAS by Armando Fox and David Patterson
• Human-Computer Interfaces by Scott Klemmer
• Game Theory by Matthew Jackson and Yoav Shoham
• Probabilistic Graphical Models byDaphne Koller
• Machine Learning by Andrew Ng (тот же класс, что идёт сейчас)

У нас есть замечательный шанс послушать некоторые знаменитые Стэнфордские курсы, записывайтесь!

Update Спасибо recky, который заметил, что добавились ещё несколько курсов. Один из CS секции — по криптографии, и два из Entrepreneurship секции:

• Cryptography by Dan Boneh
• The Lean Launchpad by Steve Blank
• Technology Entrepreneurship by Chuck Eesley

UUpdate продолжают радовать, новый доступный курс:

• Design and Analysis of Algorithms I by Tim Roughgarden

Неспособность рассуждать о коде

«Рассуждать о коде» значит понимать порядок исполнения инструкций («исполнять программу в голове»), зная, каково предназначение кода.

Симптомы

• Наличие «волшебного», «вуду» кода или кода, который не имеет никакого отношения к целям программы, но всё равно тщательно поддерживается (например, инициализация переменных, которые никогда не используются, вызов функций, не имеющих отношения к цели, создание выходных данных, которые не используются, и т.д.).
• Многократные вызовы идемпотентных функций (например, вызов save() по нескольку раз, «чтобы уж точно»).
• Исправление ошибок написанием избыточного кода, который замещает данные, полученные при исполнении неисправного кода.
• «Йо-йо код», который конвертирует значения в различные представления, а потом конвертирует их обратно ровно в то же представление, с которого начинали (например, преобразование десятичного числа в строку, а потом обратно в десятичное число, или padding строчки с последующим trim'ом).
• «Бульдозерный код», который создает впечатление рефакторинга посредством разбития кусков кода на процедуры, которые, правда, затем невозможно использовать где-либо еще (высокая когезия).

Пост подготовлен с целью помочь программистам при подготовке к собеседованиям по программированию. Здесь рассматриваются все основные темы, которые, как минимум, желательно знать перед собеседованием. Использован собственный опыт, опыт и рассказы коллег, специализированная литература.
Некоторые рассмотренные здесь темы могут вообще не пригодиться некоторым программистам, а могут и быть обязательными, решать вам. Мой совет – старайтесь как можно больше изучать темы/разделы/аспекты указанные здесь.
И так, в качестве обязательных знаний:

• Структуры данных
• Алгоритмы и «концепции»
• Язык программирования

Под катом — список из 15 лучших ресурсов, посвящённых Спортивному Программированию.

Из знакомых мне айтишников очень немногие стараются правильно произносить английские слова. Конечно, привычнее произносить C++ как «си-плюс-плюс», а не «си-плас-плас» или «опен-бэ-эс-дэ», а не «оупэн-би-эс-ди».
Но когда «echo $value;» читают как «ечо валуй» — это уже не смешно. Другой человек вас может просто не понять, особенно иностранец.

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

♫ — прослушать произношение в словаре
► — прослушать произношение на youtube

Начнем с названий:

ABBYY	аби		►
Adobe	эдоуби	[əˈdəʋbɪ]	♫
Apache	эпэчи	[əˈpætʃiː]	►	от «a-patchy»
Asus	офиц. э́сус амер. э́йсус		►
BenQ	бенкью		♫
Cisco	сискоу	[ˈsɪskoʊ]	♫
EBay	ибэй		♫
Eee PC	и писи		►
Ethernet	изэрнэт	[ˈiθərˌnɛt]	♫
Itanium	айтэйниум	[aɪˈteɪniəm]	►
Juniper	джу́нэпэр	[ˈdʒunəpər]	♫
LaTeX	лэйтех лэйтек латех латек	[ˈleɪtɛk] ['leɪtɛx] [ˈlɑːtɛx] [ˈlɑːtɛk]
Linux	офиц. линэкс вар. линукс	[ˈlɪnəks] [ˈlɪnʊks]	►
Mac OS X	мэк оу-эс тэн		►
MySQL	офиц. май-эс-кью-эл вар. май-сиквел		►	как «My Ess Que Ell», см. оф. сайт
nginx	энджин-икс		►	(от engine-x)
PuTTY	пати	[ˈpʌtɪ]		см. оф. сайт
Qt	кьют	[kyut]		см.
TeX	тех тек	[ˈtɛx] [tɛk]		не «текс»
XBox 360	экс-бокс фри сискти		♫
Xen	зен	[ˈzɛn]	♫
Xeon	зион		♫
Xerox	зирокс	[ˈzɪərɒks]	♫
Xilinx	зайлинкс	[ˌzaɪliːŋks]	►
ZyXel	рус. зайксел амер. зайзел		►	см.

Аббревиатуры:

GNU	гну		►	вар. гню
GWT	гвит	[ˈɡwɪt]
ICANN	айкэн		►
IEEE	ай-трипл-и		►	как «I triple E»
ISO	айсо		►
PNG	пинг	[ˈpɪŋ]	♫	как «ping», см. спецификацию
PXE	пикси	[ˈpɪksi]	►
RUP	рап		►
SCSI	скази	['skʌzi]	♫
SOAP	соуп	[soʊp]	►
SQL	эс-кью-эл	[ˈɛsˈkjuˈɛl]		неофиц. «сикуел»
SWF	свиф	[ˈswɪf]		см. спецификацию
WYSIWYG	визивиг	[ˈwɪziˌwɪg]	♫
XAML	зэмл	[ˈzæməl]	►
XUL	зул	[ˈzuːl]
Yii	длинное «и»	[ji:]	►

Обычно аббревиатуры произносятся по правилам английского языка: API — эй-пи-ай, PCMCIA — пи-си-эм-си-ай-эй, OpenBSD — оупен-би-эс-ди и т.д.