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



Итак, несмотря на то, что сегодня мой бизнес явно зашёл в тупик, рискну таки дать несколько советов фрилансеру-электронщику. Кстати, многие из них будут полезны и в других сферах деятельности: (к сожалению, я не нашёл в интерфейсе Хабра структурированных списков, поэтому пришлось изобразить вложение как ___)

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

В этой статье я кратко расскажу, как именно преобразуются координаты точек при повороте камеры в 3D играх, css-преобразованиях и вообще везде, где есть какие-то вращения камеры или предметов в пространстве. По совместительству это будет кратким введением в линейную алгебру: читатель узнает, что такое (на самом деле) вектор, скалярное произведение и, наконец, матрица поворота.

Привет, %username%!
Многим известно, что стандартом по умолчанию в области симметричного шифрования долгое время считался алгоритм DES. Первая успешная атака на этот неубиваемый алгоритм была опубликована в 1993 году, спустя 16 лет после принятия его в качестве стандарта. Метод, который автор назвал линейным криптоанализом, при наличии 2⁴⁷ пар открытых/зашифрованных текстов, позволяет вскрыть секретный ключ шифра DES за 2⁴³ операций.
Под катом я попытаюсь кратко изложить основные моменты этой атаки.

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

Начнем, пожалуй, с истории появления ZooKeeper. Сначала, как известно, в Google написали сервис Chubby для управления своими серверами и их конфигурацией. Заодно решили задачу с распределенными блокировками. Но у Chubby была одна особенность: для захвата локов необходимо открывать объект, потом закрывать. От этого страдала производительность. В Yahoo посчитали, что им нужен инструмент, при помощи которого они могли бы строить различные системы для конфигураций своих кластеров. Именно в этом основная цель ZooKeeper — хранение и управление конфигурациями определенных систем, а локи получились как побочный продукт. В итоге вся эта система была создана для построения различных примитивных синхронизаций клиентским кодом. В самом ZooKeeper явных понятий подобных очередям нет, все это реализуется на стороне клиентских библиотек.

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

Недавно у меня состоялся показательный разговор с Алексеем Малановым, сотрудником «Лаборатории» и опытным исследователем вредоносных программ, о том, может ли, например, сотрудник отдела по связям с общественностью (=не технарь) стать вирусным аналитиком? Ответ был простой и сложный одновременно: основы программирования, архитектура процессоров, особенности операционных систем, сетевые протоколы… В общем, «купи книжку по Ассемблеру и приходи лет через пять».

А что, если подняться на уровень выше? От анализа конкретных экземпляров вредоносных программ (что само по себе непросто) перейти к комплексному исследованию компьютерных инцидентов? Этим у нас занимается подразделение Global Research and Analysis Team (GReaT). К ним я недавно обратился с похожим вопросом: какие книги они могут порекомендовать другим специалистам по компьютерной безопасности (имея в виду, что азы программирования и прочие базовые вещи уже освоены)? В результате получился список из пяти книг — а на самом деле из десяти :-), — с которым можно ознакомиться под катом.

Здравствуйте.

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

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

Если для вас такое состояние дел кажется близким и знакомым — добро пожаловать под кат.

17-й выпуск подкаста Linkmeup посвящён глубокотехнической теме.
В гостях у нас Дмитрий Качан — аспирант СибГУТИ. Дмитрий в данный момент занимается разработкой транспортных протоколов, работающих на уровне приложений.
Поэтому сегодня мы говорим о недостатках TCP, почему сейчас он уже не может выполнять свою роль протокола с гарантированной доставкой в некоторых случаях.
Вы узнаете какие сейчас есть подходы к решению этой проблемы.

Новости выпуска

1. Правительство хочет, чтобы данные россиян хранились в нашей стране (link).
2. HP сделал свой сетевой симулятор доступным широкой общественности (link).
3. В MIT разработали технологию управления трафиком датацентра, которая многократно уменьшает задержки и очереди (link).
4. Плавный переход к теме гостя. Big Data на службе футбола (link).

Скачать файл подкаста.

Под катом вы можете найти список некоторых коммерческих решений и протоколов для эффективной передачи информации с гарантированной доставкой, а также сами исследования Дмитрия.

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

Готовимся к любым падениям

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

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

<update>

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

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

</update>

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

При написании этой статьи:

• в той или иной мере был контакт с 20+ работодателями
• выполнено 12 тестовых заданий
• пройдено 8 собеседований с техническими специалистами
• получил моральные травмы средней степени тяжести один начинающий PHP-разработчик

Баста карапузики, кончилися танцы.

В предыдущей части мы детально рассмотрели «читерские» приёмы обхода «защит» (скрытие SSID, MAC-фильтрация) и защит (WPS) беспроводных сетей. И хотя работает это в половине случаев, а иногда и чаще — когда-то игры заканчиваются и приходится браться за тяжёлую артиллерию. Вот тут-то между вашей личной жизнью и взломщиком и оказывается самое слабое звено: пароль от WPA-сети.

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

К концу статьи вы поймёте, почему ленивый 20-значный пароль из букв a-z на пару солнц более стоек, чем зубодробительный 8-значный, даже использующий все 256 значений диапазона.

Оглавление:
1) Матчасть
2) Kali. Скрытие SSID. MAC-фильтрация. WPS
3) WPA. OpenCL/CUDA. Статистика подбора

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

В последнее время мы с Vasyutka написали ряд постов (1,2,3,4) про распознавание номеров и про наш взгляд на использование системы распознавания. После публикаций было огромное количество интересных комментариев, писем и идей. Наибольшее количество мыслей и откликов было, безусловно, в стиле: «сделайте обращение в ГИБДД» и «прикрутите отправку сообщений по номерам». Но нашей основной целью было не создание приложения, а создание алгоритма распознавания, которым бы мог воспользоватся любой (хотя приложение потихоньку тоже будем развивать, оставляя исходники открытыми). Поэтому многие из идей мы ещё долго не реализуем. Но это не повод грустить! Сервисы, где всё это уже присутствует существуют. Они не очень известны, но они есть.



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

Ценник должен быть с печатью или подписью. Он является документом и обязательно должен быть на товаре. Если вы видите что-то с ценником (неважно, где и как оно стоит), вы имеете право купить его по цене на нём.

Пример: вам говорят, что товар по акции кончился. Вы видите один в витрине в герметичном ящике под потолком, но с ценником. Вам не имеют права отказать в его продаже.

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

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

• влияние задержки и пропускной способности на веб-производительность;
• ограничения, которые протокол TCP накладывает на HTTP;
• особенности и недостатки самого протокола HTTP;
• тенденции развития веб-приложений и требования к производительности;
• ограничения браузеров и возможность оптимизации.

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


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

Недавно по работе собирал своего рода лекцию по веб-безопасности, ознакомился с известным рейтингом уявзимостей OWASP 2013 года, но с удивлением обнаружил, что корректной инфы на русском языке крайне мало, или её практически нет.

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

Некоторые из предоставленных в списке уязвимостей уже расписаны и не раз — известный факт, но без них список был бы неполным. Поэтому сразу дам небольшое содержание поста:

• SQL Injection
• Некорректная аутентификация и управление сессией
• Межсайтовый скриптинг (XSS)
• Небезопасные прямые ссылки на объекты
• Небезопасная конфигурация
• Утечка чувствительных данных
• Отсутствие контроля доступа к функциональному уровню
• Подделка межсайтовых запросов (CSRF)
• Использование компонентов с известными уязвимостями
• Невалидированные редиректы
• Кликджекинг
• Фишинг
• Include

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

«Почему бы просто не взять и использовать Heroku?», спросите вы.
Прежде всего, я могу запустить Docker и Ansible на любой машине, с любым хостинг провайдером. Во вторых, я предпочитаю гибкость, удобству. Я могу, таким же образом, запускать все что угодно, не только web приложения. Ну и напоследок, потому что я эксперементатор в душе, я получаю удовольствие от понимания того как оно все вместе работает. Фундаментальная основа Heroku это Linux контейнер. Та же технология лежит и в основе Docker'a. На самом деле, одним из девизов Docker'a является «Контейнеризация это новая виртуализация»

Все последние версии браузеров поддерживают HTML5, следовательно, индустрия находится на пике готовности принять технологию и адаптироваться к ней. Сама технология создана такой, чтобы сделать простым процесс включения и обработки графического и мультимедиа-контента в вебе, без использования третьих плагинов или API. Эта статья расскажет о новых типах атак, которые HTML5 «подарил» миру.

Современный капитализм обусловил одни простой житейский «закон» — богатые становятся богаче, бедные — еще беднее. Так как больше денег -> больше возможностей заработать -> больше денег. Нам, работникам IT, немного повезло. Благодаря спросу на наш труд, который нам, чего уж скрывать, нравится, мы застряли где-то посередине — средств хватает на удовлетворение большего числа основных потребностей и еще остается небольшой излишек.

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

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

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

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