Нет смысла говорить о том, насколько это актуальный вопрос. Сегодня мы расскажем, как у нас организовано резервное копирование баз данных mysql.
И одно их самых важных – это проверка, а сделался ли бекап? А успешно ли прошел дамп? А были ли ошибки? А знаю ли я о них?

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

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

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

Этот пост навеян вот этим постом: тыц.

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

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

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

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

Ответы и свой вариант объяснения почему такое поведение логично я буду скрывать под спойлером. Сразу оговорюсь, что не претендую на непоколебимую истину своих версий и буду рад их обсудить. В разгадывании вам может помочь отличный русский перевод спецификации ECMAScript 5 за который большое спасибо iliakan!

Это перевод статьи Analysis Paralysis: Over-thinking and Knowing Too Much to Just CODE Скотта Хансельмана за 30 марта.

Прочитал сегодня пост на ArsTechnica «Я знаю слишком много чтобы программировать быстро. Что мне делать?» — это обзор вот этого вопроса на StackOverflow:

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

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

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

Данным постом мы открываем рубрику «Переводы» в нашем блоге. Почему мы решили открыть такую рубрику? Дело в том, что сотни специалистов, работающих в Mail.Ru Group, для решения стоящих перед ними задач ежедневно прочитывают множество интересных статей и постов на форумах. Некоторые из них кажутся нам интересными, и мы считаем своим долгом перевести их на русский и поделиться этими ценными знаниями с Хабражителями.

Пользуясь случаем, хотим сообщить новость: сегодня состоялось открытие Технопарка — нашего образовательного проекта, о котором мы уже не раз писали на Хабре (например, тут, тут и тут). Теперь у технопарковцев есть свое собственное помещение. Изначально Технопарк задуман как место, где талантливые студенты МГТУ им. Баумана могут получить дополнительное образование в сфере веб-разработки, дизайна и программирования, а также окунуться в работу над реальными проектами высокой сложности. В общем, у Технопарка сегодня знаменательный день, и поэтому первый выпуск в рубрике «Переводы» мы решили посвятить образовательным ресурсам для веб-разработчиков и веб-дизайнеров. Ведь пока такие Технопарки не распространились по всей стране, разработчикам зачастую приходится заниматься исключительно самообразованием.

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

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



Кошмар, товарищи!.. Как по мне, так здесь бóльший беспорядок в очерёдности строк/столбцов.

Статья описывает особенности Javascript ES3, которые имеют свойство забываться. Одни из них — странности языка, а другие просто свойства, которые, по-моему, труднозапоминаемы. Я постарался собрать здесь не те из них, по которым можно дать просто ссылку на описание языка (как по различиям между apply и call), а о которых мало сказано в руководствах.

Прежде чем начать, хочу уточнить 3 момента, которые я не стараюсь доказать этой статьёй:

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

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

Раджеш Рао (Rajesh Rao) и Андреа Стакко (Andrea Stucco) собрали установку, состоящую из двух специальных шапочек, первая из которых со вшитыми электродами, подсоединёнными к электроэнцефалографу (electroencephalography (EEG) machine), умеет общаться через Skype-соединение со второй шапочкой, подключённой к машине транскраниальной магнитной стимуляции (transcranial magnetic stimulation (TMS) machine). TMS способна путём генерации магнитных полей через специальный сердечник, укреплённый на голове испытуемого (технология неинвазивная), оказывать влияние на его мозг.

Если вы, увидев эту картинку, поняли, что ваша жизнь больше никогда не будет прежней, то вы меня понимаете. Довольно давно, более двух с половиной лет назад, совершенно случайно я увидел эту картинку на просторах интернета (кажется, на ffffound), и у меня в голове щёлкнул тумблер. Необратимый процесс был запущен.

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

Я из тех кто пришел в ИТ сферу случайно, из необходимости, но теперь желаю обосноваться надолго. В данный момент писать исчерпывающий материал по технической тематике не имею возможности, ибо сам учусь системному администрированию, в том числе и тут, но, думаю, что познание в душах пользователей, это мне удалось усвоить. Материал предназначается для тех, кто «чувствует себя не в своей тарелке» при общении с 20 летними милыми дамочками из кадров, или с БДСМного вида начальницей за 50. Поехали:

— Собеседование.

Мне рассказывали, что до моего прихода в конторе работал очень грамотный в компьютерном отношении парень. Но когда он приходил на заявку к пользователю, то из кабинета сбегали, а потом проветривали помещение. Всё потому, что он косил под мачо-рокера-байкера(или как там правильно), предпочитал не мыться, не бриться, стричь засаленные волосы по принципу — «Что бы не мешали», собственно и поведение было соответствующим — плевался, рыгал, пер**л. Я далек от того, что бы оценивать его, однако, могу предположить, что этот «набор» не ведёт в миру и пониманию.

Так уж сложилось, что последние несколько лет я занимал самые разнообразные руководящие должности в полудюжине компаний, занимающихся разработкой программного обеспечения разного рода. Довелось побывать и тимлидом, и менеджером проекта, и группы проектов, руководителем отдела и руководителем технического направления; подопечных бывало от двух до ста пятидесяти человек, да и размеры компании варьировались от трёх до двухсот тысяч работников. Неизменным оставалось только одно: чисто управленческая работа, постепенный и окончательный отход от технических задач.

А сейчас, в период между Рождеством и Новым Годом, когда особенно обострена склонность к углублённой рефлексии, приходит понимание того, что, знай я некоторые «инсайдерские» подробности управленческой деятельности заранее – сделал бы совсем другой выбор лет эдак семь назад.

Вот поэтому и родился этот немного хаотичный и очень разнокалиберный список моментов, которые очень хотелось бы передать куда-то обратно, примерно в 2005 год – дайте знать, если кто-то вдруг уже научился это делать! А пока, может быть кто-то найдёт некоторые из перечисленных ниже пунктов не до конца очевидными, или даже полезными для себя; было бы приятно осознавать, что удалось помочь кому-то сделать более осознанный выбор профессии – или просто о чём-нибудь важном задуматься.

DivShot — отличный новый инструмент для работы с Twitter Bootstrap. С помощью него создавать прототипы интерфейсов с использованием популярного CSS-фреймворка стало до безобразия просто.

На картинке изображенна турецкая снайперская винтовка с очень подходящим названием — JNG. В статье, как вы уже догадались — речь пойдёт о графическом формате JNG, а отнюдь не об оружии. На хабре уже мелькали темы, касающиеся этого формата, однако их было не много, а некоторые, к сожалению, впоследствии были удалены авторами. Не смотря на то, что JNG не особо популярный формат и базируется на формате MNG, который, судя по всему, можно считать мёртворождённым, у JNG есть одно очень хорошее свойство – это высокая степень сжатия графики с потерями плюс начиие альфа канала.
По сути JNG представляет из себя подвид формата MNG (однако со своим маркером в заголовке, позволяющим отличать оба этих формата). Цветовые данные сохраняются в JPEG формате, а вот альфа может хранится в одном из двух вариантов – либо тоже сжатая при помощи JPEG, как картинка в оттенках серого, либо используя такое же как в PNG — сжатие без потерь.
Где может пригодится JNG? Для меня он больше всего подошёл для хранения текстурных атласов в мобильных играх. Небольшой пример – исходный набор графики от игры весил 57 мегабайт, после замены всех png на jng – набор графики стал весить 15 мегабайт. Неплохой выигрыш для мобильной игры. Поиск других областей, где можно применить jng оставлю на усмотрение читателя, я же опишу чем смотреть, чем создавать а также как грузить (с примерами кода на C/C++) картинки в формате JNG, а также немного теории об его устройстве.

Предисловие

Дэниел Клиффорд сделал на Google I/O прекрасный доклад, посвященный особенностям оптимизации кода JavaSсript для движка V8. Дэниел призвал нас стремиться к большей скорости, тщательно анализировать отличия между С++ и JavaScript, и писать код, помня о том, как работает интерпретатор. Я собрал в этой статье резюме самых главных моментов выступления Дэниела, и буду обновлять её по мере того, как движок будет меняться.

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

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

— Прототипное наследование — это прекрасно
JavaScript — это объектно-ориентированный (ОО) язык, уходящий корнями в язык Self, несмотря на то, что внешне он выглядит как Java. Это обстоятельство делает язык действительно мощным благодаря некоторым приятным особенностям.

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

К счастью, в ECMAScript 5 появилось множество вещей, которые позволили поставить язык на правильный путь (некоторые из них раскрыты в этой статье). Также будет рассказано о недостатках дизайна JavaScript и будет произведено небольшое сравнение с классической моделью прототипного ОО (включая его достоинства и недостатки).

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

Зачастую бывает полезно добавить какую-нибудь дополнительную логику в код, которая собирает данные по ходу работы приложения, например подсчет количества вызовов, или обработка ошибок. Но портить существующий компактно написанный код (если конечно у вас есть такое счастье) не очень-то хочется. Решение в виде приемов АОП существует уже давно, и широко применятся. На платформах .NET и Java многие АОП фреймворки ориентируются на применение атрибутов к методам и классам. Выглядит код почти неизмененным, а в распоряжении оказывается достаточно мощный механизм расширения функциональности.

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

В первой части статьи я кратко описал принципы RESTful и объяснил каким образом следует проектировать архитектуру вашего сервера так, чтобы можно было легко выпускать новые и прекращать поддержку устаревших версий вашего API. В этой части я кратко расскажу о HATEOAS и Hypermedia, а затем расскажу о роли, которую они могут сыграть при разработке нативных приложений для мобильных устройств. Но главной темой этой статьи будет реализация кэширования (точнее поддержка кэширования на стороне сервера). Целевая аудитория включает разработчиков серверного ПО и, в какой то мере, разработчиков под iOS или под другие мобильные платформы.