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

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

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

Это не туториал, поэтому вот сразу окончательный вариант скрипта: www.webasyst.com/etc/ru/selfupdate-1 (скрипт index.php; ≈20 КБ).
Скрипт содержит класс selfUpdate, который выполняет обновление самого себя (скачивает обновленную версию файла index.php и заменяет ей работающую в текущий момент).

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

Заметка «Отказ от регистрации» взбудоражила мой ум и я часа 2 не мог уснуть (или это была чашка кофе на ночь?..)

Я и раньше читал про «мягкую» регистрацию, или отложенную регистрацию, или «ненавязчивую» регистрацию и тогда я для себя решил, что выходом будет OpenID и всё, что на него похоже. Но при работе над текущим проектом я понял, что это мне совершенно не подходит.

Решение пришло как раз перед сном, а реализацию сделал сегодня утром. Остался доволен.

Но, обо всём по порядку.

Доброе утро/день/вечер/ночь %username%!

Предыстория

В процессе реализации очередного проекта появилась необходимость реализовать эффективное оповещение пользователя о чём-либо (например, об отсутствии интернет соединения). Так как же это сделать? Стандартный класс UIAlertView оказался для этой цели слишком громоздким и скучным, и, не найдя более ничего подходящего, было решено написать своё казино с блекдже… свой класс оповещения.

Так же как и в топике — «О блоках и их использовании в Objective-C часть 2-ая», мы продолжим говорить о преимуществах использования блоков на живых примерах.
Здесь мы рассмотрим удобства использования блоков при управлении последовательностью операций.

5. UIView анимации, последовательность анимаций.

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

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

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

А что вообще такое — «биржа»?

Представьте себе магазин, в котором продаётся картошка.

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

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

• Часть I: акции, мажоритарии, контроль над компанией.
• Часть II: стоимость акций, биржа, самый лучший способ торговать картошкой, и кого же можно встретить на рынке бирже.
• Часть III: процесс IPO, его польза для компании, основателей и владельцев, а также почему у руководства компании при открытии торгов такой замученный вид.
• Часть IV: влияние IPO на доход от адулт-партнёрок.
• Часть V: жизнь после IPO.
• Часть VI: сложности выбора — два Lamborghini Gallardo или один Aventador?
• Часть VII: про инсайд.
• Часть VIII: о мотивации.

Итак, часть I: акции, мажоритарии, контроль над компанией.

Что такое акции, и для чего они нужны?

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

С акциями разобрались, теперь снова про IPO Яндекса… А откуда акции берутся изначально, при IPO, кто источник? Сам Яндекс?

Да.

В OS X 10.6 и iOS 4.0 компания Apple анонсировала поддержку блоков, по сути являющиx собою замыкания. Дальше о блоках в контексте разработки под IOS, Objective-C (тоесть работа без gc).
Для использования блоков IOS ver. < 4.0 можно применить ESBlockRuntime или PLBlocks.

Кратко о теории

Экземпляр блока, тип блока и сам блоковый литерал обозначаются с помощью оператора ^, пример:

typedef int (^MyBlock)(int);

int multiplier = 7;
MyBlock myBlock = ^(int num) {
 return num * multiplier;
};

* This source code was highlighted with Source Code Highlighter.

или

int multiplier = 7;
int (^myBlock)(int) = ^(int num) {
  return num * multiplier;
};

* This source code was highlighted with Source Code Highlighter.

Вызов блока аналогичен вызову обычной сишной функции. Например, так:

myBlock( 3 )

* This source code was highlighted with Source Code Highlighter.

Главной особенностью блоков является их умение хранить контекст в котором они создавались. В примере выше «myBlock» всегда будет умножать число на 7. Как же это все работает?

Продолжение топика — О блоках и их использовании в Objective-C часть 1-ая.

Многие из тех кто впервые сталкивается с блоками (или замыканиями), задают вопрос — «а зачем? Если и без них можно». Да можно. Но использование блоков имеет не мало преимуществ, и первое из них — существенная экономия на количестве кода, а следовательно и на времени написания и поддержке. Дальше буду говорить примерами.

Содержание:

1. Работа с контейнерами на примере NSArray.
2. Guards на примере UITableView.
3. Использование блоков вместо классов на примере scheduled операций.
4. Блоки вместо делегатов в UIAlertView.
5. UIView анимации, последовательность анимаций.
6. Асинхронные операции и управление ими. Переписываем пример с анимациями.

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

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

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

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

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

Что делать, если нужно создавать много Word файлов одинакового вида, но разного содержания? Например заполнять бланки, квитанции.

Есть 3 варианта:
1) использовать одну из библиотек для работы с Word документами
2) сохранить документ в формате docx, открыть архиватором и внутри мы увидим "\word\document.xml" — чистый xml, с которым можно работать через str_replace (спасибо Enuriru за подсказку)
3) использовать сторонний сервис, который сделает за меня большую часть работы

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

Второй варинт хорош и прост, когда мы работаем с word документами в формате .docx, но к сожалению он не поддерживает формат .doc

В процессе проработки третьего варианта, наткнулся на интересное решение LiveDocx

Преимущества:
— файл шаблона можно создать привычным способом через Word
— представление документа в форматах doc, docx, rtf, pdf
— не нужно заморачиваться с представлением Word документа через html или XML
— простота подключения
— надежность — сервис существует давно и под него даже есть готовая библиотека от Zend
Недостатки:
— в бесплатной версии ограничение на 250 генерируемых документов в сутки
— шаблон нельзя менять (например нельзя сгенерировать таблицу с кол-вом строк, равным количеству элементов в базе)

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

Извращаться приходилось всем: не только пользователям джанги, но и самим её core-разработчикам. Помните, например, как в Django 1.2 внезапно стало возможно использовать в поле username символы собаки (@) и точки? Знаете зачем? Чтобы в качестве логинов можно было использовать адреса e-mail.

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

Написать эту статью нас побудила отличная статья Данила Снитко «Как хороший договор спасает нервы и монетку».

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

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

Правила решают следующие задачи:

1. Информировать клиента о процессе работы: как будет проходить работа, что от него потребуется в процессе и когда. В результате мы получим более образованного клиента и необходимые для работы материалы вовремя.
2. Информировать клиента об ограничениях, которые мы на него накладываем в процессе работы, чтобы они не были для него сюрпризом. В результате мы получим более спокойного и удовлетворённого клиента.
3. Юридически зафиксировать договорённости, чтобы потом на них можно было сослаться. Если клиент пытается сказать, что дизайн-концепция — это свёрстанный HTML-прототип, нам есть, на что сослаться.

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

(2009 год, второе письмо старшего менеджера веб-студии — младшему)
Итак, первоначальные переговоры c клиентом проведены. Смотрим первую часть методички здесь http://habrahabr.ru/blogs/studiobusiness/45543/.
Теперь надо сориентировать клиента по цене. Если он с ней принципиально согласен — переходим к обсуждению Технического задания (ТЗ).
Делаем смету

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

Итак, получили письмо от клиента

обычно есть следующие варианты

1. клиент явно перспективный и обратился «выборочно» именно к нам — есть большая вероятность, что переговоры будут удачными — тогда лучше сразу набивать стрелку и устанавливать личный контакт и все выяснять на месте. Хотя, границы бюджета лучше выяснить в любом случае.
2. клиент интересный, но многое неясно из его письма ( нет ТЗ, нет бюджета, он написал в несколько студий, сайт потенциально сложный, сайт неинтересный и тд. ). Тут важно прислать ему БРИФ на заполнение, выяснить сроки и бюджет. Согласовать бюджет сроки — уже потом встречаться в случае, если все устраивает.
3. Письмо подозрительно короткое и не «пахнет интересом». Например, «нужен обувной интернет-магазин, сколько стоит? Как быстро сделаете? Виталий» — тут вряд-ли чтото выгорит + вероятно это пробивон по ценам от конкурентов.
   В этом случае — цену говорим в полтора раза дето дороже, интересуемся «укладываемся ли мы в их бюджет» в положительном случае — можно встречаться. Иначе — скорее всего трата времени.

«Под Windows можно писать для iPhone?»
Анонимный разработчик

«Мы не планируем публиковаться в AppStore, это ведь возможно? И еще мы хотим версию под Android...»
Анонимный заказчик

Если вы решились разрабатывать приложения для iPhone/iPad, то, скорее всего, вас заинтересуют следующие вопросы:

• как можно заработать на приложениях?
• как зарегистрироваться в iOS Developer Program и что дает регистрация?
• обязательно ли нужен Mac?
• какие инструменты можно использовать для разработки?

Иногда появляются проекты, глядя на которые возникает мысль: почему я не догадался сделать это раньше? Нечто подобное вы можете подумать о сервисе Showoff.io. Для веб-разработчика это простой и удобный способ тестировать проект в вебе и показывать заказчикам, расшарив локальный сервер через SSH-туннель. Просто устанавливаете программу, запускаете команду show с номером порта…

> gem install showoff-io
> show 3000

… и получаете рабочий URL типа https:// you.showoff.io. Работает даже через NAT.

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