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

Есть у меня серверок (да, да, именно серверок, сервером его назвать сложно). Железо старенькое (2 гига оперативы, AMD Athlon(tm) 64 Processor 3500+, програмный RAID). Админю я его сам, без особых навыков и познаний. Когда-то давным давно (больше года назад) поставил на него Debian 5.0 Lenny (это была вторая в жизни установка linux-системы, до этого ставил только Ubuntu на рабочий ноутбук) и панель управления ISPConfig3 по мануалу. Держу на нем несколько (штук 40) сайтов друзей и клиентов, Redmine, SVN и еще немного по мелочам.
Периодически все это безобразие падает (load average > 20), и приходится на сервере раз в пару часов перегружать apache или высасывать из пальца очередную попытку оптимизации. В общем полный раздрай и разруха. И вот в одну прекрасную субботу я подумал — а почему бы не решить вопрос раз и… И вот в общем.
Под катом — история убитых выходных + предыстория. Интересна в первую очередь мне, чтобы потом легко вспомнить что именно и зачем я ставил. Может быть интересна новичкам в интересном и нелегком (ох, ...) деле серверной оптимизации постепенным(!) переводом сайтов из-под Apache c его ModRewrite под Nginx (кстати, правильно это слово читается «энжинкс»меня поправили, Сысоев на конференциях не раз говорил, что название сервера стоит читать, как «энжин-икс», спасибо bayandin и DorBer ). Возможно, будет интересна более-менее опытным товарищам, оказавшимся в тех же условиях (Debian Lenny, ISPConfig3, слабое железо, несколько хороших, не сильно хороших и разных сайтов). И более опытным может быть интересно зайти, оставить пару комментариев.

Всем привет!
Процесс обработки ошибок в Yii был для меня не совсем прозрачным с первых дней использования этого фреймворка. Даже несмотря на наличие в документации специального раздела Error Handling. В каких случаях какие view используются, как влияет ajax или debug-режим, зачем нужен errorAction, в чем отличия при обработке исключений?
В итоге после копания в документации и исходном коде фреймворка я нарисовал наглядную схему обработки ошибок, которая лично для меня оказалась весьма полезной и наверняка пригодится кому-то еще.
Под катом собственно схема и некоторые комментарии к ней.

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

Всегда мне не нравилось, как выводятся изображения на моих сайтах. Хотелось какой-то упорядоченности, зависимости. Поэтому, я полез искать скрипты и решения в гугле. После безуспешных поисков, решено было делать что-то самому.
Но что? Я стал смотреть, как сделан вывод картинок у популярных сайтов. Всё мне не нравилось, пока я не додумался посмотреть вывод в google images и google+. Меня поразило то, что я никогда этого не замечал картинки выравниваются по ширине и высоте не обрезаясь. Такой принцип я и захотел реализовать. Получается мозаика. И всё будто на своём месте.
Не долго думая, я сел писать код, который сможет вывести картинки так же.

С репликацией серверов MySQL я познакомился относительно недавно, и по мере проведения разных опытов с настройкой, записывал, что у меня получалось. Когда материала набралось достаточно много, появилась идея написать эту статью. Я постарался собрать советы и решения по некоторым самым основным вопросам, с которыми я столкнулся. По ходу дела я буду давать ссылки на документацию и другие источники. Не могу претендовать на полноту описания, но надеюсь, что статья будет полезной.

Первая часть текста взята из инструкции хостинг-провайдера Netangels. Вторая — авторская.

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

Для того, чтобы быть уверенным, что ваше сообщение отправляется действительно верно, необходимо иметь по меньшей мере базовые представления о формате почтового сообщения. Формат почтового сообщения описан в нескольких стандартизирующих документах, основными из которых являются RFC 822 (описывает формат передачи простого текста на английском языке) и RFC 2045 и далее (описывает расширения этого формата для передачи произвольных данных).

Памятка начинающему экзорцисту.

Прежде, чем начать: я знаю, что такое phpDaemon и System_Daemon. Я читал статьи по этой тематике, и на хабре тоже.

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

• Запускаться из консоли и отвязываться от неё
• Всю информацию писать в логи, ничего не выводить в консоль
• Уметь плодить дочерние процессы и контролировать их
• Выполнять поставленную задачу
• Корректно завершать работу

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

// Создаем дочерний процесс
// весь код после pcntl_fork() будет выполняться двумя процессами: родительским и дочерним
$child_pid = pcntl_fork();
if ($child_pid) {
    // Выходим из родительского, привязанного к консоли, процесса
    exit();
}
// Делаем основным процессом дочерний.
posix_setsid();

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

Сегодня попробую осветить денежные вопросы.
Банковский счет, карты, платежи, PayPal и все такое.
Это продолжение топика HOWTO: свой бизнес в США из России, если кто пропустил.

    Наверняка многие из нас хоть раз думали про себя: «Черт побери, и везет же этим американцам!». Это касается многого, от магазинов с доставкой «только в пределах 48 континентальных штатов» до вполне серьезных контрактов, которые срываются только потому, что потенциальный заказчик в США категорически не желает иметь дело с иностранцами.

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

Озадачили меня тут написать демона на PHP. Т.е. скрипт, который будет заданное количество раз в заданное количество часов в случайное время (всегда случайное) выполнять определенные действия, и все это без использования cron'a.

До этого никогда не заморачивался, а тут после постановки задачи, начал было думать что так нельзя, что php скрипт надо вызывать браузером…ну задача то поставлена, надо выполнять.

Первая мысль — отключить ограничение времени выполнения скрипта. Запрещено хостером.

Вторая мысль — яваскриптом повторять аякс-запрос периодически (да хоть раз в секунду). — нельзя (требование заказчика).

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

Вступление

В недавно вышедшем iOS 5 появился удобный механизм разработки интерфейса программы — Storyboard. Этот механизм позволяет заметно уменьшить количество кода связанного с переходами между экранами, показами Popover'a и даже с настрокой ячеек в таблице.

Задача: По нажатию на кнопку показать следующий экран поместив его в текущий NavigationController.
Решение без Storyboard:

DDetailViewController* nextController = [DDetailViewController new];
[self.navigationController pushViewController:nextController animated:YES];
[nextController release];

Решение с использованием Storyboard:


Вот и все! Никакого кода!

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

Изучив синтаксис конструкции try{...}catch(Exception $e){...}, узнав о возможности создавать собственные классы исключений, наследуя их от класса Exception и поверхностно осознав мощь оказавшегося в ваших руках механизма, дальше вы можете пойти по одному из двух путей:

• Начать тут же использовать исключения. Скажем, прикручивать их к системе, в которой они никогда не использовались. Или приколачивать их к проекту, в котором ООП и не пахнет. Или, что самое ужасное, пытаться использовать их повсеместно, особенно там, где это не нужно.
• Попытаться понять, где их применять, как делать это правильно, и зачем они нужны.

Большинство прикладных приложения под iOS таким или иным образом используют UIViewController'ы. Там где UIKit фрэймворк — там и UIViewController'ы. Их много, они повсюду, они сидят в засадах и выглядывают из-за каждого угла. Поэтому, любой программист под iOS — будь он зеленым новичком, едва ступившим на тропу программирования, либо матерым профессионалом своего дела, должны знать о UIViewController'aх все.

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

Так вот. В данном посте, я еще раз расскажу о жизненном цикле UIViewController'ов, расскажу о том, что и где стоит делать, и в каком случае. Пост ориентирован на разработчиков разных уровней, так что кто-то узнает для себя что-то новое, а кто-то найдет повод отпинать моменты, на которые стоит обратить внимание Junior'ов в команде.

Всех заинтересовавшихся, прошу

Хотелось бы поговорить с вами на актуальную нынче тему, а именно — про DDoS и методы борьбы с ним. Рядовые администраторы знают, что это такое, а вот для большинства вебмастеров это аббревиатура остается загадкой до того момента пока они на личном опыте не столкнуться с этой неприятностью. Итак, DDoS — это сокращение от Distributed Denial of Service (распределенный отказ в обслуживании), когда тысячи зараженных компьютеров отправляют на сервер множество запросов, с которыми он, в последствии, не может справиться. Целью DDoS атаки является нарушение нормальной работы сервера, а в дальнейшем — «падение» сайта или сервера целиком.

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

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

Прошло уже 17 лет с тех пор, как вышла легендарная книга Банды Четырех, посвященная Паттернам проектирования (Design patterns). Несмотря на столь солидный срок, тяжело оспорить актуальность описанных в ней методик. Паттерны проектирования живут и развиваются. Их применяют, обсуждают, ругают и хвалят. К сожалению, для многих они до сих пор остаются излишней абстракцией.

Обсуждая разные вопросы программирования с коллегами как в жизни, так и на различных ресурсах, довольно часто приходится объяснять важность того или иного паттерна. Так и родилась идея на конкретных примерах показать, насколько их использование может облегчить жизнь программиста. Даже если речь идет о такой платформе, как iOS.

Полтора года назад я нажал кнопку «Опубликовать» и в блоге «Я Пиарюсь» появилась статья, определившая судьбу сервиса, являющегося сегодня лидером на российском b2b SaaS рынке. С тех пор изменилось многое: позиционирование, дизайн, размер компании, город дислокации, но главное осталось прежним. Мы делаем бухгалтерию малого бизнеса удобной, понятной, обеспечиваем клиентам высокий уровень сервиса и поддержку специалистов-экспертов.

Моё дело — это бухгалтерия онлайн, в которой есть всё необходимое для ООО или ИП, находящихся на упрощённой или вменённой системе налогообложения.

Под катом расскажу о главных моментах, позволивших нам за полтора года вырасти от стартапа с 4-мя сотрудниками до компании с представителями в 40 регионах России, засветившейся на РТР, Эхе Москвы, Ведомостях и Форбсе. Еще я напишу, чем мы отличаемся от наших конкурентов, и дам промокод на скидку.

В продолжение темы о красивой и удобной JS визуализации (http://habrahabr.ru/blogs/javascript/124899/) хочу рассказать вам о WYSIWYG редакторе, на который сегодня случайно наткнулся.

Вы наверное часто используете различные WYSIWYG редакторы в ваших проектах. Я их тоже часто использую, так уж получается, что они очень нравятся секретаршам и т.д. нашим пользователям.

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

И вот сегодня я совершенно случано наткнулся на редактор, который мне полностью подходит:

• работает стабильно
• выглядит очень стильно
• написан на jQuery

Имя этому чуду – Imperavi.
Попробуйте сами и думаю, что вам понравится.

Скриншот:


UPD
Более новая версия редактора: http://imperavi.ru/redactor/.

Изучая кодировки, я понял, что недостаточно хорошо понимаю системы счислений. Тем не менее, часто использовал 2-, 8-, 10-, 16-ю системы, переводил одну в другую, но делалось все на “автомате”. Прочитав множество публикаций, я был удивлен отсутствием единой, написанной простым языком, статьи по столь базовому материалу. Именно поэтому решил написать свою, в которой постарался доступно и по порядку изложить основы систем счисления.

Введение

Система счисления — это способ записи (представления) чисел.

Что под этим подразумевается? Например, вы видите перед собой несколько деревьев. Ваша задача — их посчитать. Для этого можно — загибать пальцы, делать зарубки на камне (одно дерево — один палец\зарубка) или сопоставить 10 деревьям какой-нибудь предмет, например, камень, а единичному экземпляру — палочку и выкладывать их на землю по мере подсчета. В первом случае число представляется, как строка из загнутых пальцев или зарубок, во втором — композиция камней и палочек, где слева — камни, а справа — палочки

Системы счисления подразделяются на позиционные и непозиционные, а позиционные, в свою очередь, — на однородные и смешанные.

Начало и оглавление см. в первой части.

Итак, моя компания вышла на IPO. Теперь я, как основатель, могу наконец-то сбросить свои акции и купить Lamborghini Gallardo! Да, я помню, что их придётся продавать «ниже рынка», но уж очень хочется прокатить Тамарку с пятого этажа на красивой спортивной машинке…

Ты весь бизнес затеял ради наживы, что ли?

(Возмущённо) Ради чего затеял — моё дело. Продам акции, куплю тачку-яхту-остров, буду наслаждаться, а дальше хоть трава не расти!

«Трава не расти», говоришь? Я правильно понимаю, что ты, основатель, хочешь выйти из бизнеса и забросить его?

У меня для тебя неприятная новость.