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

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

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

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

Но статья, на самом деле, не об этом. Я хочу рассказать про две замечательные команды git, которые я недавно для себя открыл. Это git blame и git bisect

Привожу перевод статьи Ника Карсона. В статье собраны вместе, как мне кажется, основные правила построения интерфейса для iOS приложений.

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

2. Ориентируйтесь на устройство при создании приложений: учтите не только размер экрана, но и где и когда устройство используется. Больше всего iPad используется для развлечений между 8-11 часами вечера, перед сном, тогда как iPhone — в очереди на автобус или в кофейне. Учтите различные сценарии использования при разработке приложений – включая и то, как далеко устройство расположено от лица пользователя.

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

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

5. При адаптации приложения к экранам различных размеров, помните, что при значительном его изменении – например, от iPhone к iPad – способ использования устройства также изменится. Если размеры ограничены, используйте основные функции приложения, при их увеличении – можно включить любые дополнительные функции, которые не вошли в более сжатую версию, так как у вас появляется возможность обыграть дополнительное пространство.

За остальными 45-ю — добро пожаловать подкат.

Иконка iOs приложения это ваш самый первый визуальный контакт с пользователем. Где бы он не нашел приложение в топе, в поиске, по ссылке на AppStore, вначале он обратит внимание на иконку приложения. И часто именно от нее зависит пойдет ли он мимо или на страницу с подробностями.

Из этого следует два простых правила. Я попробую продемонстрировать их на наглядных примерах.

Распределенные системы контроля версий (DVCS) постепенно замещают собой централизованные. Если вы еще не используете одну из них — самое время попробовать.

В статье я постараюсь показать, как можно быстро начать экспериментировать с git, используя сайт github.com.

В статье не будут рассмотрены различия между разными DVCS. Также не будет детально рассматриваться работа с git, по этой теме есть множество хороших источников, которые я приведу в конце статьи.

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

Основанный на трансформациях и переходах CSS3, javascript-фреймворк для создания презентаций impress.js выходит за рамки понятия “слайд” и позволяет строить презентации в открытом, неограниченном трёхмерном пространстве. Источником вдохновения для него послужил сервис prezi.com. Репозиторий impress.js на Гитхабе появился меньше месяца назад, но уже стал одним из самых популярных. Нетерпеливые могут посмотреть небольшую демку здесь, а остальные — создать пример необычной презентации прямо сейчас.

Привет, Хабр!
Сегодня я расскажу и покажу вам, как можно использовать всю мощность ваших видеокарт для игр перебора паролей к Wi-Fi. Как-то не комильфо в наше время использовать только процессорные мощности под эти задачи (в частности aircrack-ng), когда в 80% компьютеров есть видеокарта. Поэтому разумно использовать всю потенциальную мощность ваших систем. А именно, речь пойдет о замечательной программе pyrit.

Не так давно промелькнула ссылка на достаточно свежее (осень 2011) англоязычное голосование со скромным названием "самая впечатляющая книга, которую должен прочесть каждый разработчик программного обеспечения" и описанием:

Если бы вы могли вернуться в прошлое, к самому началу своей карьеры разработчика и сказать самому себе: «прочитай именно эту книгу», в самой начале своей карьеры разработчика, какую бы книгу вы рекомендовали?

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

Однако в данном небольшом посте я возьму на себя смелость перечислить ТОП-5 тех самых книг, победивших в голосовании, переведенных на русский язык. И дать небольшие комментарии, ведь книги действительно этого достойны. Да, лично я бы поменял некоторые места, однако положимся на «мнение зала» ресурса Stack Overflow.

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

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

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

Данный пост будет более продвинутой версией.

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

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

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

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

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

Сообщество JavaScript в курсе этого, особенно сообщество Node.JS, так как Node.JS ставит акцент на асинхронном коде.

Более месяца назад в статье FAQ по JavaScript: задавайте вопросы был задан вопрос «Подскажите примеры хорошего подхода организации JS кода к сайту на достаточно высоком уровне. Как можно узнать подробнее практики реализации например gmail?».

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

Эта статья о том, как сделать крупное веб-приложение расширяемым и поддерживаемым: архитектура, подходы, правила.

В стандартные VESA пазы которые есть почти у всех мониторов. Несложно. Надежно. Красиво.
С картинками и чертежами.

Что такое D-link DIR-620 и что такое Zyxel Keenetic, и для чего нужно переделывать одно в другое?
Достаточно почитать тему по DIR-620 на хоботе или на родном сайте D-link, чтобы понять что к чему. Имея неплохую элементную базу (чип Ralink 3052 2T2R на 300Мбит, 32Мб RAM и 8Мб Flash, USB порт), роутер подкачал в программном обеспечении — большинство гневных отзывов относится именно к прошивке. Хотя, чего ещё желать от устройства за 54$, позиционируемого для бюджетного сектора. Однако, Zyxel Keenetic собран на той же элементной базе, но отличается как по цене 105$, так и по программному оснащению. Заявлена поддержка USB накопителей, 3G и 4G модемов, торрент-клиент transmission прямо в роутере, и всё это реально работает. А можно ли из DIR-620 сделать Keenetic? Оказалось, что можно.



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

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

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

Что такое предложение?

Первый ответ на этот вопрос – это что-то, заканчивающееся на символы «.», «!», или «?». Но если рассмотреть встречающиеся тексты более внимательно, то можно обнаружить, что «.» используется не только для определения конца предложения, но и для аббревиатур и сокращений, а иногда выполняет обе эти роли. Вне зависимости от этого точка в 90% случаев является индикатором конца предложения (Riley 1989).

Добрый день!

В данной статье я хочу рассказать о проблеме классификации данных методом опорных векторов (Support Vector Machine, SVM). Такая классификация имеет довольно широкое применение: от распознавания образов или создания спам-фильтров до вычисления распределения горячих аллюминиевых частиц в ракетных выхлопах.

Сначала несколько слов об исходной задаче. Задача классификации состоит в определении к какому классу из, как минимум, двух изначально известных относится данный объект. Обычно таким объектом является вектор в n-мерном вещественном пространстве . Координаты вектора описывают отдельные аттрибуты объекта. Например, цвет c, заданный в модели RGB, является вектором в трехмерном пространстве: c=(red, green, blue).

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

Классификация

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

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

Предисловие

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

Продолжаем готовиться к экзамену под катом.

Предисловие

На 16 декабря сего года я назначил себе прохождение экзамена Oracle Certified Professional Java Programmer. Он же Sun Certified Programmer в прошлом. Кроме того я подтолкнул к этому важному шагу еще троих своих товарищей. Начинаем готовиться. Пока вяло, но все же… И чтобы систематизировать получаемые знания, я решил периодически составлять «выжимки» — краткое содержание того, что нашел, прочитал или испытал на собственной шкуре. То, что вы читаете в данный момент — выжимка за номером ноль. Надеюсь, что это поможет кому-то избежать покупки дорогостоящих книг и перелистывания огромного количества статей. Готовлюсь я, кстати, по книге Sun Certified Programmer for Java 6: Study Guide за авторством Kathy Sierra и Bert Bates. Хорошая книга, отличный автор, легкий язык. Рекомендую.

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