Урок курса «Android. Быстрый старт»

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

История течет так быстро, что уже только убелённые сединами хипстеры начала этого века помнят, что в одном из гаражей города Пало Альто совсем недалеко от стен альма-матери множества IT-корпораций, в том числе, Sun Microsystems – Стэнфордского Университета, в 2003 году во время товарищеской вечеринки были сформулированы основные идеи программного продукта, который позже стал мировым хитом.

Базовые ценности никто не отменял

Почему мы упомянули Стэнфорд и Sun? Не только для того, чтобы передать тот дух свободы и творчества, который царил в это время в Кремниевой Долине, но и для того, чтобы с момента своего знакомства с Android, начинающие программисты понимали – эта ОС не появилась как бы сама собой на клочке бумаги и не была написана вот так «на коленке» юным дарованием.

За ней стояли люди, которые прекрасно понимали, что и зачем они делают. А заработанные ими 130 млн. долларов в 2005 году от продажи своего продукта корпорации Google только это доказывают.

Deleted Deleted

Предисловие

Не знаю, все ли программисты всесторонне любознательные люди, но я всегда пытаюсь получить фундаментальные знания во всех областях, которые могут быть практически полезны. В то время, когда мне в голову пришла эта идея я изучал анатомию и физиологию по журналам «Тело человека. Снаружи и внутри», ну а по работе я занимался стерео-варио фотографиями (для тех кто не знает — были такие советские календарики с ребристой поверхностью, где картинка либо казалась объемной, либо менялась). Так вот, в один из вечеров мне пришла в голову замечательная идея, которую я на протяжении уже 4х лет использую для поддержания своего зрения.
Обещаю, что эффект почувствуете сразу!

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

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

Поэтому, когда жареный петух клюнул, я быстренько пробежался по интернету, прочитал пяток свежих обзоров и решил заказать себе Asus Transformer Infinity c этим самым доком. Цена вопроса — 31500р, плюс 500р. за срочную доставку. На момент покупки это было ровно 950 американских долларов. Что из этого вышло? Да ничего хорошего. Читайте дальше.

Почти неделя прошла с исполнения хабрахабру 6 лет. Было бы очень интересно посмотреть на графики роста показателей сайта. Т.к. стандартная статистика малоинформативная, решено было собрать всю информацию своими руками и проанализировать. И так, почти неделя парсинга и сбора информации и получены следующие интересные данные(скрытые/удаленные посты/пользователи и их комментарии не учтены):

• Больше всего постов написал alizar — 4298, рекорд 12 постов в день поставлен 18 октября 2006
• Больше всего комментариев написал VolCh — 19323, установив личный рекорд 27 июля 2011 года в количестве 140 комментариев.
• Больше всех опубликовал постов в день freetonik —21 топик 26 августа 2007
• Максимальная активность хабры в день — опубликовано 105 топиков: 18 февраля 2010 и 22 июня 2008 года.
• Максимальная активность хабры в месяц — опубликовано 2055 топиков в марте 2010
• Среднее значение кармы: +7,83
• Средний рейтинг топика: +24,75
• Всего комментариев: 3 703 022.
• Средний рейтинг комментария: +0,98
• Максимальное количество оставленных комментариев — 1 июля 2011 в количестве 4936 штук.
• 25% из всех опубликованных топиков были перенесены в черновики
• Самый комментируемый топик habrahabr.ru/post/123157 собрал 2252 комментария

Красивые графики, методы измерения, база с полученными данными, «хаброаномалии» — все это под катом.

Надежная передача данных в Интернете осуществляется на базе протокола TCP (Transmission Control Protocol), спецификация к которому была опубликована почти 30 лет назад. Алгоритм TCP (RFC793), позволяет подключенному устройству адаптироваться для работы в сети на скоростях в пределах десятков мегабит в секунду и задержки до 100 секунд. С бурным развитием новых технологий передачи данных, уже через 10 лет после внедрения стало ясно что производительность протокола не будет хватать для более широких каналов.

В vim 7 появились табы — привычный способ навигации по файлам. Когда я работал в eclipse я не раз замечал, что часто скакать между табами не удобно, а знакомство с буферами в emacs натолкнуло на прочтение документации по окнам/буферам в vim.

Хай, Хабр!
Сегодня я хочу представить, дорогому хабрасообществу свой первый хабраперевод. Программировать на языке Python — подобно песне. Но еще лучше, когда Ваш код читаем и понятен, а значит чуть более поэтичен, чем обычно бывает производстве. У каждого свои правила и свои стереотипы относительно написания и оформления исходного кода, на каком бы языке он ни был написан. Множество копий сломано о щиты на форумах, но, как ни крути, нельзя не считаться с мнением авторитетных товарищей. Так что сейчас будет представлен перевод первой части стайл-гайда для языка Python от Google. Коснется он именно постулатов написания кода (вторая часть тоже скоро появится, а посвящена она будет форматированию исходного кода). Сразу предупреждаю: тут много (если не большая часть) прописных истин, которые все знают уже давно. Но я искренне надеюсь, что Вы сможете найти тут что-то новое или хотя бы вспомнить старое. Приступим под катом. И pdf тут как тут.

Создание пакетов или packet crafting — это техника, которая позволяет сетевым инженерам или пентестерам исследовать сети, проверять правила фаерволлов и находить уязвимые места.
Делается это обычно вручную, отправляя пакеты на различные устройства в сети.
В качестве цели может быть брандмауэр, системы обнаружения вторжений (IDS), маршрутизаторы и любые другие участники сети.
Создание пакетов вручную не означает, что нужно писать код на каком-либо высокоуровневом языке программирования, можно воспользоваться готовым инструментом, например, Scapy.

Scapy — это один из лучших, если не самый лучший, инструмент для создания пакетов вручную.
Утилита написана с использованием языка Python, автором является Philippe Biondi.
Возможности утилиты практически безграничны — это и сборка пакетов с последующей отправкой их в сеть, и захват пакетов, и чтение их из сохраненного ранее дампа, и исследование сети, и многое другое.
Всё это можно делать как в интерактивном режиме, так и создавая скрипты.
С помощью Scapy можно проводить сканирование, трассировку, исследования, атаки и обнаружение хостов в сети.
Scapy предоставляет среду или даже фреймворк, чем-то похожий на Wireshark, только без красивой графической оболочки.
Утилита разрабатывается под UNIX-подобные операционные системы, но тем не менее, некоторым удается запустить ее и в среде Windows.
Эта утилита так же может взаимодействовать и с другими программами: для наглядного декодирования пакетов можно подключать тот же Wireshark, для рисования графиков — GnuPlot и Vpython.
Для работы потребуется права суперпользователя (root, UID 0), так как это достаточно низкоуровневая утилита и работает напрямую с сетевой картой.
И что важно, для работы с этой утилитой не потребуются глубокие знания программирования на Python.

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

Вот пример фото, сделанного с его помощью:

Как вы, наверное, догадались, эта статья посвящена lock-free очередям.

Очереди бывают разные. Они могут различаться по числу писателей (producer) и читателей (consumer) – single/multi producer — single/multi consumer, 4 варианта, — они могут быть ограниченными (bounded, на основе предраспределенного буфера) и неограниченными, на основе списка (unbounded), с поддержкой приоритетов или без, lock-free, wait-free или lock-based, со строгим соблюдением FIFO (fair) и не очень (unfair) и т.д. Подробно типы очередей описаны в этой и этой статьях Дмитрия Вьюкова. Чем более специализированы требования к очереди, тем, как правило, более эффективным оказывается её алгоритм. В данной статье я рассмотрю самый общий вариант очередей — multi-producer/multi-consumer unbounded concurrent queue без поддержки приоритетов.

Данная статья касается современных линуксов. Например, RHEL6 с ядрами 2.6.3х — подойдёт, а вот RHEL5 с ядрами 2.6.18 (кстати, наиболее популярный в продакшне) — увы, нет. И ещё — здесь не будет описания ядерных отладчиков или скриптов SytemTap; только старые-добрые простые команды вида «cat /proc/PID/xyz» в отношении некоторых полезных узлов файловой системы /proc.

Диагностика «тормозящего» процесса

Вот хороший пример часто возникающей проблемы, которую я воспроизвёл на своём лаптопе: пользователь жалуется, что команда find работает «значительно медленнее», при этом не возвращая никаких результатов. Зная, в чём дело, мы решили проблему. Однако меня попросили изложить систематический подход к решению подобных задач.

К счастью, система работает под управлением OEL6, т.е. на достаточно свежем ядре (а именно — 2.6.39 UEK2)

Итак, приступим к диагностике.

После нескольких часов чтения обзоров, Боб с нетерпением нажал на кнопку перехода к оформлению заказа на галлон цельного молока, и…
Воу, что только что произошло?

Введение

Многие интересуются Full-Mesh (или P2P) VPN, хотят использовать их для игр с друзьями, для связи удаленных офисов, серверов, да для чего угодно. Обычные VPN, вроде OpenVPN или PPTP, пропускают весь трафик через центральный сервер, а Full-Mesh соединяются непосредственно с нодами, зачастую пробивая NAT.

Введение

Я собираюсь рассказать об однострочных программах на Perl. Если вы овладете однострочным Perl`ом, то можете сэкономить кучу времени (я экономлю).

Цель поста — показать как Perl можно использовать заместо find, grep, awk, sed. В конце поста будет написано зачем это надо.

Как частый посетитель тэга PHP на StackOverflow, я очень часто встречаю вопросы о том, как распарсить какие-то конкретные аспекты HTML, используя регулярные выражения. Самый распространённый ответ на это:

«Ты не можешь парсить HTML с помощью регулярных выражений, потому что HTML не является регулярным. Используй XML парсер, и будет тебе счастье»

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

Определение высоконагруженных систем и способов их построения

      Нагрузка на сервер — это важный показатель использования серверного оборудования. Хит – это запрос клиента к серверу для получения информации. Нагрузка сервера определяется как отношение количества клиентских запросов (хитов) ко времени, выражается в хитах в секунду. Согласно исследованиям Microsoft в 2010 году высоконагруженным сервером можно считать сервер с нагрузкой 100-150 хитов в секунду.
      В литературе встречаются такие понятия как HPC-система, высоконагруженная система, высоконагруженный кластер, Highload-система, суперкомпьютер, которые порой используются как синонимы. Мы будем понимать сайт с нагрузкой не менее 150 хитов в секунду.
      Кластер – это группа компьютеров, которые работают вместе и составляют единый унифицированный вычислительный ресурс. Каждый узел работает под управлением своей копии операционной системы, в качестве которой чаще всего используются Linux и BSD.
      Чтобы понять каким образом задачи, выполняемые кластером, распределяются по его узлам необходимо дать определение масштабироемости. Масштабируемость — способность системы справляться с увеличением рабочей нагрузки (увеличивать свою производительность) при добавлении ресурсов. Система называется масштабируемой, если она способна увеличивать производительность пропорционально дополнительным ресурсам. Масштабируемость можно оценить через отношение прироста производительности системы к приросту используемых ресурсов. Чем ближе это отношение к единице, тем лучше. Также под масштабируемостью понимается возможность наращивания дополнительных ресурсов без структурных изменений центрального узла системы. Масштабирование архитектуры высоконагруженной системы может быть горизонтальным и вертикальным. Вертикальное масштабирование заключается в увеличении производительности системы за счёт увеличения мощности сервера. Главный недостаток вертикального масштабирования в том, что оно ограничено определённым пределом. Параметры железа нельзя увеличивать бесконечно. Однако на самом деле вертикальная компонента присутствует практически всегда, а универсального горизонтального масштабирования как такового не существует. Горизонтальное масштабирование заключается в увеличении производительности системы за счёт подключения дополнительных серверов. Именно горизонтальное масштабирование является сейчас фактически стандартом. Известен также такой термин, как диагональное масштабирование. Оно подразумевает одновременное использование двух подходов.
      И наконец, необходимо определить основной принцип, использующийся при построении любой кластерной архитектуры. Это — трёхзвенная структура системы (рис. 1). Три звена – это фронтэнд, бэкэнд и хранилище данных. Каждое звено выполняет свои функции, отвечает за различные стадии в обработке запросов и по-разному масштабируется. Первоначально запрос приходит на фронтэнд. Фронтэнды отвечают, как правило, за отдачу статических файлов, первичную обработку запроса и передачу его дальше. Второе звено, куда приходит запрос, уже предварительно обработанный фронтэндом — это бэкэнд. Бэкэнд занимается вычислениями. На стороне бэкэнда, как правило, реализуется бизнес-логика проекта. Следующий слой, который вступает в дело обработки запроса – это хранилище данных, которые обрабатываются бэкэндом. Это может быть база данных или файловая система.

Вместо предисловия

Я приветствую всех, кто читает этот пост!
В последнее время мне стали часто задавать вопросы, связанные с SIEM. Окончательно добило общение с товарищем, с которым мы собрались вечером попить пивка и как-то незаметно перешли на тему, связанную с безопасностью. Он сказал, что они собираются внедрять SIEM — потому что «она помогает защитить инфраструктуру». И даже нашли людей, которые им соглашаются сделать это «за недорого и быстро». Вот тут-то я и насторожился… Как выяснилось, они думали, что внедрение SIEM разом избавит их от неприятностей вроде утечки данных, и к тому же будет недорогим и быстрым — мол, нашли систему, которая не требует настройки. Ну и дела, подумал Штирлиц, и решил накропать свои соображения по этому поводу, дабы отправлять вопрошающих к печатному источнику. Постараюсь быть кратким и охватить наиболее часто задаваемые вопросы.

В общем-то на Хабре достаточно постов о фрилансе вообще, и о Elance.com в частности — пост ниже является попыткой поделиться опытом.
Информации много не бывает — посему позвольте начать.

Если вы впервые слышите про Elance — настоятельно рекомендую прочитать два поста ниже, serjio очень хорошие советы даёт по поводу регистрации, наполнения портфолио, бидов и прочего, что необходимо знать:

• Как начать работать на Elance.com. Краткое руководство для веб-дизайнера.
• Работа на elance для новичков. Часть2

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

Обычно люди сходу начинают предлагать готовые реализации кеша, вроде memcached или HTTP-кеша, но это лишь ответ на вопрос где кешировать.

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