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

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

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

Эту завесу тайны мы сегодня и приподнимем, и поможет нам в этом — серная и азотная кислота.

Внимание! Любые операции с концентрированными (а тем более кипящими) кислотами крайне опасны, и работать с ними можно только используя соответствующие средства защиты (перчатки, очки, фартук, вытяжка). Помните, у нас всего 2 глаза, и каждому хватит одной капли: потому все что тут написано — повторять не стоит.

Планета Lave на задворках галактики, видавший виды Cobra MK III, 100 кредов, а дальше — крутись, как хочешь. Так начиналась Elite — легендарная игра восьмидесятых. Оригинальная версия игры для компьютера BBC Micro вышла в 1984 году. В нашей стране наибольшее распространение получила спектрумовская «Элита» — 40 килобайт, томительно грузившиеся с кассеты несколько минут, а внутри — бесконечное разнообразие галактик и звёздных систем, богатых и бедных, высокороазвитых и отсталых, спокойных и смертельно опасных, подстерегающие в гиперпространстве таргоиды и легенда о невозможной планете Raxxla…

Недавно я начал нелёгкое дело по вёрстке диссертационной работы в LaTeX-е. Естественным первым желанием было найти какой-нибудь готовый шаблон. Увы, я не нашёл ничего, что подходило бы под мои нужны. Поэтому я решил сделать свой шаблон (с преамбулой и макрокомандами)! Сразу скажу по поводу соответствия шаблона ВАК-овским требованиям: строгих требований нет (можете сами посмотреть список нормативных документов). Однако определённые требования могут быть у конкретного совета (но они, как правило, весьма похожи и соответствуют здравому смыслу). В своём шаблоне я постарался учесть общие тенденции в оформлении такого рода работ. Не буду приводить кучу технических особенностей вёрстки в LaTeX (на эту тему и так хватает статей), а просто поделюсь готовым результатом: GitHub.

Введение

Данная история началась примерно год назад. Сам я по специальности автоматчик, занимаюсь разработкой и внедрением систем автоматического управления технологическими процессами (АСУТП). В основном работа состоит в разработке прикладного программного обеспечения в специализированном ПО, так называемом SCADA-пакете. Для тех, кто не знаком с понятием SCADA и с чем его едят — подробно можно ознакомиться здесь. Достаточно долго проработал в компании отечественного разработчика подобной системы, начав с тестировщика, прошел через техподдержку, дорос до уровня руководителя отделом системной интеграции, выполнял разработку проектов автоматизации под ключ на базе ПО, которое разрабатывала компания. В процессе разработки проектов, очутившись в шкуре конечного пользователя продуктом, часто приходилось дорабатывать инструментарий под конкретные задачи напильником, потому как функционал или глючил, или не дотягивал до должного уровня. А все прения с разработкой и маркетингом по развитию продукта либо упирались в нежелание что-либо делать со стороны разработки, либо все списывалось на то, что у меня руки кривые и я ничего не понимаю в колбасных обрезках. Долго так продолжаться не могло, и вот в один прекрасный момент наши пути с этой компанией разошлись, я ушел к одному из своих крупных заказчиков продолжать делать то, что делал им же на заказ, но уже в штате этого заказчика.

Некоторое время назад я публиковал статью о самодельных микропроцессорах, сегодня же мы затронем более сложную и щекотливую тему (особенно в свете событий на Фокусиме) – создание ядерного реактора, способного генерировать энергию в домашних условиях. И перед тем как вы начнете волноваться, вспоминая о негативных опытах в прошлом (см. Радиоактивный бойскаут – наковырявший прилично амерция-241 из детекторов дыма) заранее скажу, что все что описано в этой статье – относительно безопасно (по крайней мере не опаснее работы с фтороводородной кислотой дома), но крайне не рекомендуется к повторению. Перед любыми действиями проконсультируйтесь со своим адвокатом — законы разные в разных странах. Много кто уже сидит.

Бывает, что Хабр прочитан, мировые новости изучены, новая книга не начата и хочется какой-нибудь качественной технической информации — заметок от программистов, ссылок на интересные новости от западных коллег и просто гиковских штук. Как быть в этом случае? Можно обратиться к западной технической блогосфере, к счастью, там есть из чего выбрать. Но и отечественная блогосфера с программистским и гиковским уклоном способна порадовать самого придирчивого читателя. Под катом собраны ссылки на самые любопытные (по мнению автора) блоги российских IT-деятелей. На Хабре уже было что-то похожее, но без описания и четкой тематики. Приведенные здесь блоги будут интересны скорее программистам.

Наверное, у каждого программиста возникала ситуация, когда совершенно не знакомые с IT люди просили его объяснить, в чём же состоит суть его профессии. Так уж сложилось, что у большинства людей понятие «программист» ассоциируется либо с замкнутым гиком в очках и свитере, либо с неким гениальным красноглазым подростком-хакером — но при этом никто не знает, чем именно он занимается.

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

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

Form Builder



Этот прекрасный генератор форм поможет вам в создании красивейших CSS логин-боксов и прочих input вещей, при минимальных временных затратах. Помимо форм на сайте этого проекта можно создавать и другие не менее красивые CSS элементы, в том числе кнопки и ленты.

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

В этой статье я хочу рассказать об автоконфигурации в облаке. Для примера запустим ec2-инстанс, на котором «приготовится» WordPress.

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

Целью данной заметки я ставлю в подробностях описать организацию сервера для Rails приложений в самой популярной на данный момент связке: rvm + Rails + Nginx + Unicorn. К написанию статьи побудило отсутствие полной пошаговой документации по этой связке, понятной не только ядреным профессионалам этой области. Далее я попытаюсь подробно, шаг за шагом, описать идеологически правильный процесс организации сервера для обслуживания нескольких Rails приложений (на примере одного) — если у вас есть абсолютная уверенность в том, что на подопытной машине никогда не будет работать более одного приложения — настройка может быть существенно короче и проще. Хочу предупредить, что тонкости, касающиеся работы приложения под высокой нагрузкой в статье не описываются, т.к. цель ставилась иная — заставить работать приложение в связке и сократить количество конфликтов с другими приложениями до минимума.

Привет, Хабр!
Все программисты делятся на тех, кто использует систему контроля версий, и тех кто ещё ёё не использует. Одной из самых популярных на сегодняшний день, является git. И хотя его структура направлена на децентрализованное хранение данных, все мы пользуемся github, assembla, bitbucket или githost. Главный недостаток этих хостингов, в том, что это чужие проекты, которые в любой момент могут прикрыть ваш аккаунт или слить данные налево. И тут на сцене появляется GitBlit! Git сервер на Java, полностью контролируемый вами, с множеством плюшек и веб-интерфейсом. Сегодня будем запускать его на бесплатном хостинге от Redhat.

abstract: В статье описаны продвинутые функций OpenSSH, которые позволяют сильно упростить жизнь системным администраторам и программистам, которые не боятся шелла. В отличие от большинства руководств, которые кроме ключей и -L/D/R опций ничего не описывают, я попытался собрать все интересные фичи и удобства, которые с собой несёт ssh.

Предупреждение: пост очень объёмный, но для удобства использования я решил не резать его на части.

Оглавление:

• управление ключами
• копирование файлов через ssh
• Проброс потоков ввода/вывода
• Монтирование удалённой FS через ssh
• Удалённое исполнение кода
• Алиасы и опции для подключений в .ssh/config
• Опции по-умолчанию
• Проброс X-сервера
• ssh в качестве socks-proxy
• Проброс портов — прямой и обратный
• Реверс-сокс-прокси
• туннелирование L2/L3 трафика
• Проброс агента авторизации
• Туннелирование ssh через ssh сквозь недоверенный сервер (с большой вероятностью вы этого не знаете)

Мне по работе часто приходится сталкиваться с высоконагруженными многопоточными или многопроцессными сервисами (application-, web-, index-server).
Достаточно интересная, но иногда неблагодарная работа — оптимизировать все это хозяйство.
Растущие потребности клиентов часто упираются в невозможность просто заменить железную составляющую системы на более современную, т.к. производительность компьютеров, скорость чтения-записи жестких дисков и сети растут много медленнее запросов клиентов.
Редко помогает увеличение количества нодов кластера (система как правило распределенная).
Чаще приходится запустив профайлер, искать узкие места, лезть в source code и править ляпы, которые оставили коллеги, а иногда и сам, чего греха таить, много лет назад.
Некоторые из проблем, связаных с синхронизацией, я попытаюсь изложить здесь. Это не будет вводный курс по многопоточному программированию — предпологается, что читатель знаком с понятием thread и context switch, и знает для чего нужны mutex, semaphore и т.д.

Современные системы мониторинга “из коробки” позволяют отслеживать практически все показатели отдельного узла системы, но обладают рядом существенных недостатков

• зная все об одном узле, о работе системы в целом они не имеют никакого представления — попробуйте из коробки выдать руководству “в данный момент у нас 1200RPS на фронте, 90% страниц отдается за 300мс, 95% за 650мc, системных ошибок и таймаутов происходит меньше 10 в секунду” (см картинку под катом)
• выход за рамки одного из системных показателей одного из узлов системы еще не значит, что стоит бить тревогу — возможно узел попал под повышенную нагрузку, или разработчики сменили алгоритм
• в рамках мониторинга отдельных узлов практически невозможно уследить постепенную деградацию сервиса — как правило он срабатывает только когда уже “ничего не работает”
• деградация производительности внешних сервисов не отслеживается в принципе (вас никогда не банил CDN?)

На исходной у нашей площадки более 1.000.000 уников, ~100.000.000 http запросов на фронтенд в сутки и развесистый, в плане сопровождения, зоопарк проектов. Набор ключевых слов — nginx, apache, php (двух вариаций), oracle. С заядлой периодичностью возникают ситуации “у нас все работает” по отдельно взятым зонам ответственности либо, что тоже не редкость, “у вас ничего не работает”. На границах ответственности идет сплошная передача тикетов.
Мы не стали изобретать велосипед и решили сделать мониторинг по времени и корректности отклика пользователю с отслеживанием отклика бекендов, а также какие из них были задействованы при обработке конкретного запроса. Ну и плюс наши объемы — не сильно большие, но несколько граблей по ходу изложения можно продемонстрировать.

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

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

Введение

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

Хочется продолжить свою предыдущую тему об алгоритмах сжатия. В этот раз я расскажу об алгоритме LZW и немного об его родственниках алгоритмах LZ77 и LZ78.

Алгоритм LZW

Алгоритм Лемпеля — Зива — Велча (Lempel-Ziv-Welch, LZW) — это универсальный алгоритм сжатия данных без потерь.

(Окончание перевода статьи Эдди Османи о сравнении и выборе библиотеки для проекта со значительной ролью JS на клиенте.)
Содержание первой части:

■ Что такое MVC или, лучше сказать, MV*?
■ Когда нам нужен MV*-фреймворк JS?
■ Где же мы будем нуждаться в MV*, а где нет?
■ Проблема выбора: слишком много вариантов?
■ TodoMVC: общее приложение для обучения и сравнения
■ Предложенные нами критерии выбора фреймворка
■ Dojo и усложнение фреймворков на JavaScript
■ Коллекция TodoMVC (фреймворки, на которых сделаны реализации тестового приложения Todo)