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

Для чего это еще может пригодиться? В наше время смс сервисы используются достаточно широко. Способов их реализации достаточно много. У меня недавно возникла необходимость реализовать сервис, при котором клиенты могли бы посылать смс сообщением номер заказа и в ответ приходил бы его статус. Задача решилась так: за 500 руб., на барахолке был куплен старенький Nokia 7610 в разваливающемся состоянии, у которого не работала половина кнопок, были проблемы со звуком и т. д. Туда была вставлена сим карта от местного оператора с безлимитным смс пакетом. Теперь этот аппарат будет играть роль сервера, который будет работать в режиме 24/7, с бесперебойным источником питания (аккамулятор), и не будет знать проблем с охлаждением :)

Вступление.

Часто в документации от Qt встречается термин Pimpl. Кроме того, те кто хоть немного копался в исходном коде Qt часто видел такие макросы как: Q_DECLARE_PRIVATE, Q_D. А также встречал так называемые приватные заголовочные файлы, название которых заканчивается на "_p.h".
В этой статье я попробую приоткрыть ширму за всей это структурой.

Pimpl, что это?

Pimpl — Pointer to private implementation. Это одно из названий паттерна программирования. Еще его называют чеширским котом — «Cheshire Cat» (это название мне больше нравится). В чем суть этого паттерна? Основная идея этого паттерна — это вынести все приватные члены класса и, в не которых случаях, функционала в приватный класс.
Отсюда название «чеширский кот» — видно только улыбку, а все остальное остается невидимым, но оно несомненно есть :-) Кто не помнит этого замечательного кота, может обратится к первоисточнику, к книге Льюиса Кэрролла «Алиса в стране чудес». Очень интересная книга, особенно если читать в оригинале.
Что это дает?

Появилось желание сделать сервис подобный letitbit.net в отдельно взятой стране на окраине Европы.
Требовалось:

• позволять загружать/отдавать большие файлы;
• не позволять перепубликовывать прямые ссылки на файлы;
• ограничивать количество одновременно скачиваемых файлов.

Для реализации выбрали NGINX в связке с PHP через fastcgi.
В NGINX добавили:

1. великолепный Nginx upload module, который позволяет избежать многократное копирование загруженного файла на пути NGINX-PHP. К тому же, при небольшой доработке, возможна загрузка сразу в нужную папку, что позволяет использовать простое переименование вместо копирования в PHP
2. нужную заплатку к модулю secure_link, позволяющую делать безопасные ссылки действительными ограниченное время

PHP взяли самый обычный и запустили через spawn-fcgi.
Поставили сервачок, напихали туда штук 12 терабайтных дисков.
Программист написал PHP код, а Марис Рускулис придумал следующий трюк с rewrite для NGINX, позволяющий избежать обращение к PHP при скачивании файла.
В результате, конфигурация NGINX выглядела примерно так:
http {
limit_zone regular $zonekey 10m;
limit_zone premium $zonekey 10m;
server {
root /www/oursiteishere;
location / { try_files $uri @files; }
location ~ \.php$ { try_files $uri @files; fastcgi_stuff_here; }
location @files { rewrite ^(.*)$ /index.php?$1 last; }
location /storage/ { root /storages/; internal; }
# Location for regular users
location ~ /download/.+/(.+)/0/.+/.*/(.+)$ {
set $fname $2;
set $username $1;
set $zonekey "$binary_remote_addr $username";
limit_conn regular 1;
limit_rate '100k';
secure_link_secret megasecret;
secure_link_ttl on;
if ($secure_link = "") { return 403; }
add_header Content-Disposition "attachment; filename*=UTF-8''$fname";
rewrite ^/download/([a-f0-9]+)/([\.~0-9a-zA-Z_]+)/([01])/([0-9]+)/(.+)/.+$ /storage/$4/$5 break;
}
# Location for premium users
# Location for upload using upload module
}
}

Замечательной вещью в данном конфиге является тот факт, что при скачивании файла по сгенерированной защищённой от подмены временной ссылке (проверку осуществляет secure_link) не вызывается PHP с последующим X-Accel-Redirect.
Возможно, данное решение накладывает ограничение на присутствие логики перед непосредственной отдачей файла, но тем не менее, на мой взгляд, является довольно оригинальным трюком, позволяющим немного сэкономить на fastcgi.

Добрый день смотрим сразу как это работает:



Zen Coding
chikuyonok — Сергей Чикуёнок
pepelsbey — Вадим Макеев

Этот способ ускоренного написания HTML и CSS кода разрабатывается Сергеем Чикуёнком, который «знает толк в извращениях».

HTML код пишется на CSS манеру:
div#content>h1+p

Нажимаем нехитрое комбо на клавиатуре (Ctrl+,) и получаем результат:
<div id="content">
    <h1></h1>
    <p></p>
</div>

мой первый TCP Сервер был создан пару лет назад. Основой создания послужила книга Р.Стивенсона «Unix — Профессиональное программирование.» Есть несколько подходов к созданию TCP-серверов. В данном посте хочется рассказать про классический TCP сервер.

Очень многие начинающие программисты думают, что знают, как написать Hello World. Естественно, с этого примера ведь и начинается большинство учебников.
А давайте посмотрим, как это делается.
Обычно в учебнике по C эта программа выглядит примерно так:
#include <stdio.h>
void main()
{
    printf("Hello world\n");
}

Небольшое вступление

    Собственно, тогда, давно, я решил попробовать Qt, потому что часто слышал об удобстве разработки под него и своими глазами видел, какая шикарная документация представлена на сайте производителя. Не могу сказать, что это далось легко (я раньше немного писал на GTK), особенно путался в этих бесконечных классах на "Q", но постепенно начало нравиться все больше и больше. В частности потому, что есть отличная привязка к нему для языка Python, на котором я, собственно, в основном и пишу.
    Еще почему? Ну, я мог бы рассказать и о том, что он работает как на почти всех настольных системах, так и на многих мобильных, рассказать про совершенно гениальную объектную систему виджетов и т. п. Но — зачем? Не люблю холивары с приверженцами других визуальных библиотек :) Поэтому давайте считать этот топик чем-то вроде дележки опытом и рассуждений на тему.

Разработка, основанная на специфицировании поведения (BDD), — один из краеугольных камней философии Ruby.

Очень удачной реализацией BDD является всем знакомый RSpec. Одной из замечательных черт RSpec является его расширяемость.

Так, мы используем RSpec совместно с Factory Girl (хотя стоило бы перейти на Machinist), RR (прекрасный каркас для заглушек), Spork и недавно перешли с Shoulda на Remarkable.

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

Хорошим способом сделать это является создание нового «ожидателя» (matcher).

14й выпуск computer science student и второй, посвященный языку Scheme. В сегодняшнем коротком скринкасте я расскажу о том, что такое лямбда в функциональном языке программирования.

Видео доступно на vimeo, youtube и rpod.

Использование V8, заключение

Часть 3 находится здесь: habrahabr.ru/blogs/development/72765

Часть 2 находится здесь: habrahabr.ru/blogs/development/72592

Часть 1 находится здесь: habrahabr.ru/blogs/development/72474

Если здесь HD-режим недоступен, значит нужно перейти на vimeo.

Знакомство с языком программирования Scheme в рамках проекта CS Student. В видео мы познакомимся с некоторыми простыми типами данных, порядком обработки процедур и выполним парочку заданий из моего курса Programming Paradigms. Во второй части будет решение задачек немного посложнее и знакомство с другими возможностями языка. Ссылки:

• Scheme на Wikipedia (англ)
• Самоучитель Scheme на нашей Wiki
• Оригинал самоучителя «Teach Yourself Scheme in Fixnum Days»
• Полный текст задания

Интерпретаторы

• PLT Scheme (Dr. Scheme)
• MIT/GNU Scheme
• Kawa
• 3DScheme
• Bigloo
• Schemeway
• PVTS

Сегодня на Hacker News наткнулся на пост о (похоже очень) новом языке "ooc". Бросил на день все дела, занялся ковырятельством — уж больно интересно выглядит.

Итак, "ooc — это современный, объектно-ориентированный, функционально(ватый), высокоуровневый, низкоуровневый, секси язык программирования". (Именно секси его и представляют разработчики, ну а я бы добавил что еще и "компилируемый")

По сути — ooc — транслятор языка высокого уровня в C со сборщиком мусора.

Как выразился один из посетителей сайта: "ooc для C, — это как Scala для Java" (jimbokun@HN).

Обязательный «Hello, World» на ooc:

hello.ooc:

"Hi, softer world =)" println()

на выходе hello.c и hello.exe.

ooc-компилятор транслирует это в c-код и использует доступный c компилятор (gcc, mingw, icc, tinycc) чтобы сделать из этого hello.exe (или ./hello). Поддержка tinycc заявлена, но в реальности ждем поддержки C99 в самом tinycc (автор обещал сделать обходные пути, но пока не работает), поэтому наслждаемся пока что довольно неслабого размера .exe'шниками (gcc от mingw других не делает).

Итак, что у нас уже есть в языке: классы, объекты, строгая типизация, угадывание типов (n := "Beer" length()), chaining (.dothis().dothat()), совместимость с c-библиотеками, абстрактные классы, шаблоны из C++, списки, разреженные(sparse) списки, хеши (ArrayList, SparseList, HashMap), for (i in list) { ... }, обертки для c-шных функций и классов, перегрузка операторов, полиморфизм, сборщик мусора (отключаемый), import file/name (не нужны .h, но .h можно использовать как extern), closures, eiffel's contracts, исключения, reflections, pattern matching, ranges, ternary operator, bindings, generics, coroutines, GTK, SDL, OpenGL, GLU, GLUT bindings…

Как сказал товарищ varjag@HN: «Я думаю это розыгрыш, сделанный пользователями Ruby, но нигде этого в тексте не вижу.» Нет, этот язык существует на самом деле. Примеры, линки, установка, подводные коряги — под катом…

С момента публикации первого топика о создании хабраподобной статистики (которую, кстати, почему-то тут не обновляют) с импортированием данных из Google Analytics прошел ровно год.



Весь этот год все работало, статистика обновлялась, графики рисовались… пока все не сдохло. Как это и присуще гуглу, сдохло оно не сразу у всех, а потихоньку, в течение недели. При беглой диагностике проблемы выяснилось, что она заключается в гугловой авторизации. Учитывая, что скрипт авторизации мною был заимствован, разбираться в нем не было никакого желания, и тут до меня дошло — ведь Google выпустил API для аналитикса! Поэтому было решено не обрабатывать напильником существующую версию, а просто получить данные цивилизованно, посредством API, тем не менее, оставив при этом «структуру» и основные моменты предыдущей версии.

В IT индустрии все чаще встречаются проекты с распределенными командами. Это удобно — спецификация, код, баги, мануалы легко перемещаются из одного конца планеты в другой за доли секунд. Это выгодно — аутсорсинг проектных процессов, будь то разработка, тестирование или саппорт, в Индии или Китае обойдется в 3–5 раз дешевле аналогичных сервисов в странах Европы или США.

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

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

Требования

— Должна быть известна начальная высота родительского блока;
— Дочерний блок может иметь произвольный размер как по высоте, так и по ширине.

Возможности

— Работает в IE6+, O9+, FF2+, webkit;
— Тру vertical-align выравнивание со всеми допустимыми значениями;
— Одинаковое поведение во всех браузерах (незначительные отклонение при некоторых условиях в ие6 будут оговорены ниже);
— При вырастании дочернего блока выше «папочки», родительский блок расширяется;
— Ни грамма JavaScript.

Сегодня был неожиданно удивлен, какие удобные штуки таит в себе MySQL. ;-)

Хочу представить вашему вниманию фичу MySQL — профайлинг.
Появилась она начиная с версии 5.0.37.

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

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

Итак, как пользоваться:

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

Введение

С момента написания мной предыдущей статьи по оптимизации этой связки прошло довольно много времени. Тот многострадальный Pentium 4 c 512Мб памяти, обслуживающий одновременно до тысячи человек на форуме и до 150,000 пиров на трекере уже давно покоится на какой-нить немецкой, свалке, а клуб сменил уже не один сервер. Всё сказанное в ней всё ещё остаётся актуальным, однако есть вещи которые стоит добавить.
Статья большая, так что будет поделена на логические блоки:

0. Зачем вообще что-то оптимизировать?
  
1. Оптимизация ОС (FreeBSD)
  1.1 Переход на 7.х 
  1.2 Переход на 7.2
  1.3 Переход на amd64
  1.4 Разгрузка сетевой подсистемы
  1.5 FreeBSD и большое кол-во файлов
  1.6 Softupdates, gjournal и mount options
  
2. Оптимизация фронтенда (nginx)
  2.1 Accept Filters
  2.2 Кеширование
  2.3 AIO
  
3. Оптимизация бэкенда
  3.1 APC
  3.1.1 APC locking
  3.1.2 APC hints
  3.1.3 APC fragmentation
  3.2 PHP 5.3
  
4. Оптимизация базы данных
  4.1 MySQL 
  4.1.1 Переход на 5.1
  4.1.2 Переход на InnoDB
  4.1.3 Встроеный кеш MySQL - Query Cache
  4.1.4 Индексы
  
4.2 PostgreSQL
  4.2.1 Индексы
  4.2.2 pgBouncer и другие.
  4.2.3 pgFouine
  
4.3 Разгрузка базы данных
  4.3.1 SphinxQL
  4.3.2 Не-RDBMS хранилище
  4.4 Кодировки
  4.5 Асинхронность
  
Приложение. Мелочи.
  1. SSHGuard или альтернатива.
  2. xtrabackup
  3. Перенос почты на другой хост
  4. Интеграция со сторонним ПО
  5. Мониторинг
  
 6. Минусы оптимизации

Бодрый день, хаброчеловеки!

Что такое Redis?

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

Чем Redis отличается от существующих решений?

API для работы с Memcached (MemcacheDB) позволяет хранить массивы, но эти массивы будут сериализованы и сохранены как строки, таким образом атомарные операции над такими массивами не возможны.
Redis позволяет хранить как строки, так и массивы, к которым можно применять атомарные операции pop / push, делать выборки из таких массивов, выполнять сортировку элементов, получать объединения и пересечения массивов.

Производительность

110000 запросов SET в секунду, 81000 запросов GET в секунду на Linux-сервере начального уровня (тесты).

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

Sharding

Redis, как и Memcached, может работать как распределённое хранилище на многих физических серверах. Такой функционал реализуется в клиентских библиотеках, и к сожалению, «из коробки» этот функционал реализован пока только в Ruby API, однако это не мешает вам хешировать ключ самостоятельно и получать ID сервера, к которому с этим ключом обращаться.

API

API доступно для следующих языков:

• Ruby
• Python
• PHP
• Erlang
• Tcl
• Perl
• Lua
• Java

API для PHP доступно как в виде модуля, написанного на C, так и в виде PHP5 класса, который общается с Redis-сервером через сокеты, таким образом не требуется устанавливать модуль.
Кроме того существует PHP5 класс от отечественного разрабочика (с именем, заслуживающим доверия. Я серьёзно.) — IMemcacheClient. (Спасибо DYPA за наводку)

Перспективы развития

Разработка ведётся очень активно, комиты происходят почти каждый день, сейчас доступна версия Redis 0.900 (1.0 release candidate 1), которая очень скоро станет версией 1.0
В ближайшем будущем авторы обещают внедрить разные интересные фичи, в том числе и сжатие данных.

Лицензия и поддерживаемые платформы

Redis — написан на ANSI C и работает на большинстве POSIX-систем (Linux, MacOS X). Это бесплатное открытое ПО под BSD лицензией =)

Up: Rediska — удобный PHP-клиент для key-value базы Redis. Оф.сайт.

Сегодня наткнулся во френдфиде исследователя фонда inVenture Ярослава Грешилова на 9 интереснейших правил проектной работы. Оговорюсь, что далеко не со всем здесь согласен, но пища для размышлений тем не менее превосходнейшая. Привожу здесь в удобном для чтения виде.

UPD от Ярослава: «Это не «правила Ярослава Грешилова», а правила *для* Ярослава Грешилова. И направлены они вовсе не на проектную работу, а на то, чтобы не потерять себя. Обсуждение того, что происходит с проектами при применении этих правил, не входило в мою задачу.»

Правило первое: работать имеет смысл не «над проектами», а «с людьми». Проекты всё равно имеют свойство со временем мутировать до неузнаваемости, а вот люди, как правило не меняются.

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

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

Правило второе: нельзя полностью растворяться в том, что ты делаешь, и ассоциировать себя с этим делом. Мои проекты — это не я. Они — лишь средство моего движения, самовыражения, исследования этого мира.

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