Всем доброго времени суток! Новогодние праздники позади, все хорошо отдохнули. Тем не мнеее, даже в праздники иногда появляется работа. Мне, к примеру, довелось покопаться в чужом коде на Python. Код хороший, замечательно документирован, но во время чтения не покидало ощущение, что автор читал доки по Python и портировал код с Си-подобного языка. Это меня вдохновило на написание статьи с указанием ошибок, которые неизбежно возникают при переходе на Python с Си-подобных языков.

Статья пригодится тем, кто недавно пишет на этом языке, а также для тех, кто пишет на нем маленькие скрипты, не заморачиваясь на деталях.

Прелюдия

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

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

Недавно мне пришлось доточить одно расширение Оперы под себя, раньше я ими совершенно не занимался. Открываю код, о ужас! Куча непонятных цепочек пространств имен (window.opera.extension.tabs, window.opera.contexts.toolbar, window.opera.extension.broadcastMessage) которые с первого взгляда и не пойми что таят (я и не ждал легкого пути). Пришлось открыть dev.opera.com для дальнейшего изучения. Расширение я все-таки доточил и решил заодним написать фрэймворк, который значительно упрощает разработку расширений для Оперы.

CANVAS шаг за шагом:

1. Основы
2. Изображения
3. Понг
4. Пятнашки

Если верить англо-русскому словарю, то можно узнать что canvas переводится как холст, а если верить википедии, то можно узнать что тег canvas, это элемент HTML 5, который предназначен для создания растрового изображения при помощи JavaScript. Тому как создать это растровое изображение и будет посвящен мой небольшой текст. Прежде чем начинать пробовать свои силы в этом не легком деле рекомендуется уже иметь базовые знания о том что такое HTML и с чем едят JavaScript.

Применение

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

Решение

В качестве решения я предлагаю схему PHP<->Dropbox. Dropbox нам интересен тем, что каждому новому пользователю выделяеся 2Gb виртуального дискового пространства, а так же возможность отката на предыдущие версии файлов. Это обеспечивает нам стабильное хранилище, в котором не возникнет случаев безвозвратно удаленных файлов.

Когда-то давно, когда я практиковался в написании хранимых процедур, триггеров, курсоров под MSSQL, мне не давала покоя мысль о приложении, где вся бизнес-логика крутится на уровне БД, а presentation tier просто дергает базу и отвечает за отрисовку полученных результатов. С тех пор прошло много моих девелоперских лет, но возможности для реализации данной идеи так и не встретилось… до тех пор, пока я не наткнулся на CouchDB.

Я думаю, что многие уже слышали о NoSQL базах данных и в том числе о Couch DB. Здесь я хочу рассказать о замечательной возможности встраивать JavaScript-приложения в CouchDB, название которым CouchApp.

Все мы тут собрались умные, образованные, красивые и опытные. И на сегодняшний день, мне кажется, почти все используют тот, или иной вид RPC между JavaScript и PHP, который работает на API из того, или иного фреймворка. Кое кто даже разрабатывает какие-то свои костыли и подпорки. Я не исключение, конечно же. Правда пошел я по пути наименьшего сопротивления и, собственно, речь в этой статье пойдет как раз об этом — об очередной реализации XML\JSON RPC для JavaScript и PHP.

Предыстория такова, что мне необходимо было разработать некую систему управления данными. Естественно, что данные хранятся в СУБД, а управлять ими надо через веб. Привязываться к фреймворкам готовым очень не хотелось, потому выбор был не велик — PHP-быдлокодинг, или MVC с рендерингом на основе готовых разработок вроде smarty. Однако, примерно в то же время, я обратил внимание на такие проекты как extJS (он же Sencha теперь) и qooxdoo, которые позволяют создавать полноценные веб-приложения минуя утомительную HTML-верстку, генерацию HTML/XML, XSLT преобразования и многие другие «страшные» вещи, характерные для MVC и PHP-быдлокода. Потому созрел следующий план действий.:

Привет!

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

Задача перед мини-стартапом стояла простая:

• Создать прикольную штуку на «коленке» за минимум времени
• Потратить на запуск меньше 1000 рублей (время не считается)
• Собрать работающий монетизируемый сервис

UDP: в комментах ещё есть статистика во время хабраэффекта и феерический конец истории от агрегатора.

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



Итак…

1. Отсутствие фирменной концепции (логотипа, слогана, и т.п.).

Первое, во что упирается мой взгляд при заходе на страницу – логотип сайта и слоган под ним. И благо, если на сайтах магазинов есть хотя бы логотип. Из 50 магазинов, выданных гуглом по разным конкурентным запросам, логотипа не было у 6. Не так уж и много, но и не так уж мало.

Многие владельцы интернет-магазинов банально не понимают (лично спрашивал) – огромная часть продаж строится на бренде. У человека в голове есть ряд ячеек, заполненных брендами известных фирм. К примеру, «наушники – Koss», «операционная система – MacOS X», «газировка – Coca-Cola», и т.д. и т.п. Первоочерёдная задача фирменой концепции – заполнить ячейку «интернет-магазин — ?» вашим названием. Тогда пользователь будет возвращаться снова и снова.

Недавно был снова обновлен центр по Internet Explorer на MSDN. Были добавлены 76 статей и книг, посвященных следующим темам:

• HTML,CSS3 и DHTML
• JavaScript, AJAX, DOM и JQuery
• Расширения
• Производительность
• Совместимость

Полный список материалов со ссылками под катом

Как это работает

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

2. P2P слой позволяет связывать два или более компьюторов или столько сколько позволяет сеть или настройки файрвола. Это означает что AeroFS будет работать в Интернете, в локальной сети и в вашем офисе.

3. Т.к AeroFS полностью распределённая система, если сервера AeroFS будут в дауне то у пользователя все будет работать.

Социальный портрет платящего пользователя в приложениях Моего Мира

Монетизация социального приложения – крайне важный вопрос для любого разработчика.
Естественно, что на определенном этапе каждая студия начинает задаваться вопросом: как оптимизировать приложение под платящую аудиторию социальной сети?

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

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

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

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

AJAX и все, все, все

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

Нетрудно заметить, что все больше сайтов используют AJAX и частичные обновления страниц, причем в невероятном количестве. В частности, «начиненные» AJAX ссылки могут использоваться для внутренней навигации по странице, переключения каких-то вкладок. Это хорошо тем, что
А) меньше данных нужно перегонять от сервера — только нужный кусок страницы и
Б) веб-страницы часто загружают просто гигантские CSS и JavaScript-файлы, которые при AJAX-обновлении можно повторно не загружать.

Итак, очень распространено построение приложений по сценарию: одна большая «стартовая» страница, загружающая весь JavaScript-код и CSS и более мелкие «внутренние» функциональные блоки, загружаемые через AJAX. С этим есть ряд проблем:

1. В результате AJAX-действий внутреннее состояние страницы не отражено в адресной строке браузера.
2. Как следствие, внутренние страницы не могут быть запомнены в закладки, нельзя «отправить ссылку другу».
3. Не работает Back/Forward навигация в браузере, т.к. AJAX-ссылки не попадают в историю браузера.

Однако крупные сайты нашли некое «хакерское» решение, которое мы сейчас рассмотрим и напишем небольшой свой собственный аналог на Grails и jQuery.

День 16 ноября 2010 года навсегда войдёт в историю Creative Commons в России. В этот день по предложению вашего покорного слуги на официальном сайте Creative Commons появились русские переводы т.н. «Commons Deed» (краткого объяснения лицензий). Так как русский язык на территории бывшего СССР является lingua franca, теперь все русскоязычные люди из бывших республик могут легко понимать условия лицензий Creative Commons! Пожалуйста, обновите ссылки в ваших проектах (в Википедии ссылки уже обновлены).

• Creative Commons Attribution 3.0 Unported
• Creative Commons Attribution-ShareAlike 3.0 Unported
• Creative Commons Attribution-NoDerivs 3.0 Unported
• Creative Commons Attribution-NonCommercial 3.0 Unported
• Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported
• Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported
• CC0 (CCZero)
• Public Domain Mark
• Copyright-Only Dedication* (based on United States law)
  or Public Domain Certification

Белорусские переводы также доступны.

Node.js — вещь, вокруг которой сейчас много шума, восторженных отзывов и гневливых выкриков. При этом, по моим наблюдениям, в умах людей закрепилось следующее представление о том что же такое Node.js: «это штука, позволяющая писать на JavaScript на серверной стороне и использующая JavaScript-движок от Google Chrome». Поклонники языка восторженно вздохнули: «Ах! Сбылось!», противники же процедили сквозь зубы: «Ну вот только еще этой ерунды с прототипами и динамической типизацией нам на серверах не хватало!». И дружно побежали ломать копья в блоги и форумы.

При этом многие представители обоих лагерей придерживаются мнения, что Node.js — это эзотерическая игрушка, веселая задумка для переноса языка браузерных сценариев на «новые колеса». Дабы быть до конца честным, признаюсь, что я так же придерживался подобной точки зрения. В один прекрасный момент, я набрался духу и решил «копнуть поглубже». Выяснилось, что создатель Node.js Райан Дал далеко не фанатик, а человек, пытающийся решить реальную проблему. А его творение — не игрушка, а применимое на практике решение.

Впервые о своем бизнесе я задумался в начале 2008 года. Мне нужны были инвестиции, поэтому я очень много общался со всевозможными инвесторами, а также мнимыми инвесторами и консультантами по поиску инвесторов. На общение с ними я потратил очень много времени, и большая часть его была потрачена впустую. Хочу поделиться накопленным опытом общения с инвесторами и дать несколько советов другим стартапщикам.

Много слов сказано о том, как правильно писать юнит-тесты, и вообще о пользе TDD. Потом ещё и какое-то BDD замаячило на горизонте. Приходится разбираться, что из них лучше и между ними какая разница. Может, это и есть причина, почему большинство разработчиков решили не заморачиваться и до сих пор не используют ни того, ни другого?

Коротко: BDD — это дальнейшее развитие идей TDD, стало быть, его и надо использовать. А разницу между TDD и BDD я попробую объяснить на простом примере.

Рассмотрим 3 ревизии одного юнит-теста, который я нашёл в одном реальном проекте.

Попытка номер №1

Первая версия этого юнит-теста была такой:

Топик навеян впечатлениями от докладов на swpiter и постом о том, как не продать машину :)

Как работать над стартапом и всегда оставаться в выигрыше?

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

Картинка слева кликабельна, а ниже — текстовое описание в 12 шагах как инициировать стартап и при этом всегда оставаться в выигрыше.

1. Идея!

И так, всё начинается с идеи, которая каким-то образом пришла к вам в голову. Идея выглядит интересной и соблазнительной. Она мотивирует вас.

Самое важное в идее — это не терять мотивацию вплоть до 10 шага и тогда вы в любом случае получите для себя выгоду.

2. Детализация идеи

Необходимо хотя бы примерно ответить на эти вопросы:

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

На этом этапе ещё рано отвечать на вопросы:

• сколько времени вы можете уделить (если идея вас реально интересует, вы перейдёте к следующим этапам)
• сколько на это нужно денег
• кто вам ещё нужен для реализации идеи

Заметка навеяна постом Помогите, а то я скоро сойду с ума (реальная история, реальной разработки проекта), затем была опубликована как комментарий, а теперь, по просьбам, и как топик.

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

И так, как же разработать стартап лучше?

Пошаговый план эффективного запуска первой версии: