Начал изучать NodeJS. Нигде не нашел актуальный стек мейнстримных библиотек (технологий) применяемых в node. Поэтому решил сам составить список.

Часто путают терминал и шелл. В тех же *nix есть шеллы (bash, csh, zsh, …) и терминалы (konsole/guake/yaquake/tilda и т.д. и т.п.) Для мира Windows общеизвестный терминал только один – стандартное консольное окошко, которое часто ошибочно называют «cmd.exe». И мало кто знает о существовании множества других эмуляторов терминала. Известных шеллов больше, их целых два: cmd.exe и powershell.exe. И хотя есть как минимум три порта bash (MinGW, CygWin, GIT) многие юниксоиды предпочитают ругать cmd.exe.

Меня не устраивал ни один из найденных альтернативных терминалов (как в 2009-м, когда я начал работу над ConEmu, так и сейчас). Казалось бы требований немного, вот основные:

Я давний подписчик блога «GTD» (уст. Учись работать).

С 2008 года я активно читал статьи на Хабре и в Интернете и пробовал:
— вставать в 5:00 утра
— делать зарядку
— обливаться холодной водой
— бегать по утрам
— питаться правильно (особенно зачитывался вегетарианством)
— вести свои делало системе GTD (Things установлен на всех гаджетах :)
— выключать компьютер вовремя (хотя бы до 23:00)
— ну и конечно, сделать 100 отжиманий и кубики на животе…

Ммм… Вы уже наверное догадались через сколько дней заканчивались порывы моей души и все возвращались на круги своя? :) Я думаю не ошибусь, если скажу, что таких как я очень и очень много.

Что изменилось в январе 2012 года?

Рано… в начале кратко обо мне:
— Возраст: 26 лет;
— Семейное положение: женат (с февраля 2012), детей пока нет;
— живем отдельно в Санкт-Петербурге.
— Работаю в офисе 5 дней в неделю с 8:30 до 17:30.
— Иногда задерживаюсь, но не часто.

Если Вы считаете, что опыт Вам не подойдет… Ваше право, но мы же понимаем, что оправдания всегда можно придумать? Я их придумывал лет 5. Я знаю о чем говорю.

На Хабре несколько раз писали о системах менеджмента конфигураций puppet и chef, но по какой-то причине первопроходец этой темы — cfengine, обделен вниманием, давайте воспоним этот пробел.

Предисловие

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

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

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

Партия реверансов сделана, тылы прикрыты, паноптикум можно считать открытым.

Уверен, что голая теория вам нужна не более чем собаке пятая лапа. Признаюсь также, что все разы, когда я сталкивался с голой теорией, заканчивались крепким сном. Когда-то давно, когда я только начинал изучать первый пакет трехмерного моделирования, купив пару толстенных книг и проигнорировав при этом известное положение о том, что важен совсем не размер, со мной начали приключаться удивительные вещи. На первых же страницах. Я засыпал. Позорно. В тех позах, в которых меня застигала чертова книга. Везде. Даже в метро.

Я не хочу того же для вас. Хочу, чтобы история была интересной, а посему – долой нудную теорию, долой правила, лекторский тон и никому не нужный апломб. Никаких графиков, таблиц и сравнений. Только эмоции и веселье, по возможности, наподобие этой работы. Один из артов которые я изготовил во время компании в поддержку финансирования разработки игры Wasteland 2.



Что же останется в статье, если убрать особливо техническую информацию, — спросите вы?

Хочу познакомить хабрапользователей, касающихся прямо или косвенно вопросов защиты информации, с практически не упоминавшимся на Хабре замечательным методическим ресурсом: “NIST Special Publications 800 Series”.

NIST – National Institute of Standards and Technology – американский национальный институт стандартизации, аналог отечественного ГосСтандарта. В его составе функционирует компетентный и имеющий серьезный вес в США центр по компьютерной безопасности – CSRC, объединяющий специалистов федеральных служб, университетов, крупнейших ИТ-компаний США. Центр публикует с начала 1990-х годов Стандарты (FIPS) и более детальные разъяснения/рекомендации (Special Publications) в области информационной безопасности. Рекомендациям (Special Publications), созданным CSRC, присваивается код 800. О них я и предлагаю поговорить подробнее.

Приветствую всех в этот прекрасный день ожидания праздника, это моя первая статья на хабре, в которой я хотел бы рассказа про открытый API погоды Яндекса. Статья является продолжением серии Java для начинающих. Следует отметить, статья рассчитана на тех, кто недавно начал изучения язык или на тех, кто не знаком с данным сервисом, но в любом случае, рад я буду любым читателям (эх тавтология… ). Яндекс дает неплохую возможность для разработчиков, которым требуется в своей программе или на своем сайте разместить погоду, причем информации, которую Яндекс предоставляет более, чем достаточно.

Погоду Вы сможете выбрать за любой день на неделю вперед. Различные состояния (ясно, пасмурно и т. д.), множество языков (для городов, например русский и английский, для состояний все языки стран СНГ и не только: ясно, аяз, açık, ашық и т… д.), я не очень хорош в географии, но, кажется, информация там для всех стран, даже есть миниатюрные картинки состояния погоды, но самое главное, почему я выбрал этот сервис — простая и понятная структура. Сразу оговорюсь, за «рекламу» мне не платили.

Осенью 2008 года мы потратили две-три недели свободного от основной работы времени, чтобы написать маленькую утилитку для бэкапа баз данных (MS SQL Server и потом MySQL). Сегодня она приносит нам около $230 000 в год и можно с уверенностью говорить, что суммарно мы заработаем на ней больше $1 000 000.

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

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

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

Задача банальная — заменить переводы строк на <br/>, за исключением случая, если перед этим шел html-тэг (для простоты только символ >). Отходя от темы — такой алгоритм замены нужен чтобы иметь и автоматическое добавление переводов строки внутри блоков текста в стиле хабра, и при этом не ломать обычную HTML верстку.

Мы живем в удивительное время, то что раньше казалось очень сложным внезапно становится доступным и простым. Задачи для решения которых надо было создавать научные институты и крупные организации, сейчас решаются саморганизованными группами энтузиастов. Энтузиасты создают карты и энциклопедии снимают фильмы и разрабатывают software. Я хочу рассказать о той области, в которую этот свежий ветер перемен еще не подул в полную силу – это погода. И нашим проектом – OpenWeatherMap — мы хотим изменить эту ситуацию!

В предыдущей статье рассматривалась теория и практика прогрессивного улучшения (progressive enhancement). В этой статье мы от идеологии перейдем к аксиологии и рассмотрим финансово-экономическую обоснованность применения прогрессивного улучшения.

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

Введение

Как известно, nginx умеет кешировать ответ сервера, и выдавать его по запросу вместо обращения к бэкенду, экономя тем самым ресурсы сервера. Скорость отдачи таких закешированных страниц иногда поражает, ради таких скоростей иногда не жалко переносить на javascript многие функции сайта только для того, чтобы иметь возможность закешировать ещё 1 страницу целиком (Например, вынести отрисовку плашки с авторизацией юзера на js, чтобы иметь возможность кешировать страницу, которая идентична для всех пользователей, за исключением этой самой плашки).

Я много раз использовал возможность кэширование nginxом страниц, и натыкался на пару неудобных для себя вещей:

• Можно легко закешировать вообще все страницы, но для динамических сайтов или для сайтов с авторизацией нужно ли это?
• Можно закешировать отдельно несколько url, вида /album/*, но не переписывать же конфиг nginx каждый раз при появлении новых разделов сайта?

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

Этот топик открывает цикл статей по использованию системы управления конфигурацией Puppet.

Что такое система управления конфигурацией?

Предположим, что у вас есть парк серверов, выполняющих различные задачи. Пока серверов мало и вы не растёте, вы легко настраиваете каждый сервер вручную. Устанавливаете ОС (может быть, автоматизированно), добавляете пользователей, устанавливаете софт, вводя команды в консоль, настраиваете сервисы, правите конфиги ваших любимых текстовых редакторов (nanorc, vimrc), выставляете на них одинаковые настройки DNS-сервера, устанавливаете агент системы мониторинга, настраиваете syslog для централизованного сбора логов… Словом, работы довольно много и она не особенно интересна.

Webshell.io предназначен для создания прототипов и мэшапов на основе JavaScript API различных веб-сервисов. Что-то вроде IFTTT, но для программистов. С его помощью можно в интерактивном режиме писать запросы на JavaScript и CoffeeScript к клиентским и серверным API Google, Facebook, Twitter и многих других популярных сайтов и видеть их ответы в консоли, а так же создавать свои приложения, API которых, в свою очередь, будет доступен другим разработчикам. Webshell также поддерживает рендеринг HTML из шаблонов EJS.

Прочитав недавний топик "Использование try — catch для отладки" решил все таки в качестве дополнения поделиться и своим опытом.

В этой статье предлагаю рассмотреть получение callstack’а места, где было брошено исключение в случае работы со
структурными исключениями (MS Windows). В детали работы исключений вдаваться не будем, т.к. это тянет на отдельный цикл статей (для интересующихся рекомендую Рихтера, MSDN и wasm.ru). Конечно, есть много уже готовых проектов для генерации minidump’ов (например CrashRpt или google-breakpad), так что эта статья носит больше образовательный характер.

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

Этот пост снова посвящается цикловым оптимизациям. Почему вообще речь зашла о цикловых перестановочных оптимизациях? Дело в том, что это одна из самых эффективных частей оптимизирующего компилятора. В число цикловых перестановочных оптимизаций входит как автовекторизация так и автопараллелизация. У этих оптимизаций существует своя специфика, но в целом у всех цикловых оптимизаций общие проблемы и общие методы их решения.
Часто приходится слышать мнение, что компилятор во многих случаях «тупит». Мне хочется здесь побыть адвокатом компилятора, чтобы показать, что жизнь компилятора не так уж легка, возможно вызвать легкую долю сочувствия к его нелегкой доле и показать, какие существуют объективные трудности при обработке программы и почему во многих случаях компилятор совершенно обоснованно не может сделать ту или иную оптимизацию, которая кажется очевидной программисту. Ну и заодно я хочу продемонстрировать некоторые возможности помочь компилятору в его работе. Понятно, что иногда существуют и субъективные факторы, в лице разработчиков, которые по како-либо причине не реализовали ту или иную функциональность внутри компилятора.

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

Привет!

Вы используете утилиты командной строки для управления серверами и сервисами AWS? Как же надоело обновлять и качать их из разных мест. Да и неоднородность команд тоже не радует…

AWS официально выпустили консолидированный CLI, который в последствии будет включать в себя все доступные сервисы. А сейчас можно управлять

• Amazon Elastic Compute Cloud (Amazon EC2)
• Elastic Load Balancing
• Auto Scaling
• AWS CloudFormation
• AWS Elastic Beanstalk
• Amazon Simple Notification Service (Amazon SNS)
• Amazon Simple Queue Service (Amazon SQS)
• Amazon Relational Database Service (Amazon RDS)
• AWS Identity and Access Management (IAM)
• AWS Security Token Service (STS)
• Amazon CloudWatch
• Amazon Simple Email Service (Amazon SES)

Пару лет назад я начал пользоваться различными сервисами для развития своих способностей — LinguaLeo, Codecademy, Coursera. Это просто отличные инструменты. Удивительно, но тогда я не нашел подобного сервиса, который помог бы моему хобби — музыка (гитара). Идея создать отличный сервис для гитаристов, включающий в себя образовательную платформу, созрела в декабре 2011 года. История проекта Totallicks банальна.

Что такое хелпдеск? Система управления заявками пользователей, личинка сервисдеска, первый шаг эникейщика на пути к ITIL, бла-бла-бла…



Литература, посвященная вопросу организации системы управления инцидентами (заявками пользователей, проблемами в ИТ — называйте, как хотите) делится на две категории. Первая включает в себя технические низкоуровневые мануалы, посвященные, в основном, тонкостям настройки конкретных решений. Такие работы могут рассказать в подробностях, как добиться прироста производительности в WonderDesk величиной 0.001% под SuperSQL v.0.0001 alpha, но, как правило, ничего не говорят о том, зачем вообще нужен этот WonderDesk, и, главное, что с ним, существенно ускоренным, потом делать.

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

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