Сантьяго Сваллоу (Santiago Swallow) — визионер, консультант, автор и мыслитель. У Сантьяго 85 тыс. фоловеров в твиттере и статья в Википедии. Пожалуй, по состоянию на 17 апреля это был самый «известный» человек в интернете, про которого никто не слышал. Оно и неудивительно, ведь Сантьяго на самом деле не существует.

Создание образа Сантьяго Сваллоу заняло всего два часа и 68 долларов.

Некоторые приемы сокращенных вычислений знать очень полезно. Кроме того, эти приемы часто любопытны и сами по себе. Поэтому считаю не лишним познакомить с ними и читателей Хабра.

итак…

За несколько лет, читая новости и события в мире Web разработки, у меня нарисовалась розовая мечта: написал один раз — работает везде и всегда. При этом очень часто встречаю негативные отзывы о разработке мобильных приложений на HTML5 ( тут и комментарии на статьи 1 и 2 ). Основные доводы бастующих: несоответствие родному интерфейсу, глючность и тормознутость, проблемы с хранением данных и тд и тп. Ни в коем случае не хочу запустить очередные холи вары на эту тему. Но мечта живет и ее можно подтвердить или отвергнуть только после собственного наступления на грабли.
Итак, цель – написать на HTML5 мобильное приложения для сбора заказов торговым агентом в торговых точках. Я сталкивался с данными решениями разных компаний, поэтому знаком с предметной областью, и эта тема идеально подходит для мечты.

На фотографии — чеклист самолета Cessna: в какие положения нужно установить переключатели перед запуском двигателя, допустимые полетные параметры и так далее. Пилот не в первый раз видит этот список. Выучить — раз плюнуть. Но мозг может перезаписывать информацию, создавая ложные воспоминания, но при этом при «запросе» данные будут помечены как «верные». А вот напечатанное на бумаге не изменяется, поэтому ей можно доверять на 100%. SEO — это не управление самолетом с сотней человек на борту. Потерять можно всего-то несколько десятков тысяч рублей (если, например, начать продвижение с закрытыми от индексации в robots.txt страницами). Но не проще ли потратить 5-10 минут на проверку и убедиться, что все сделано правильно?..

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

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

Я очень ленив, чтобы серьезно заниматься риск-менеджментом. Всегда считал это полной чушью, созданной неудачниками для отмазок в стиле: «А! Мы же говорили, что у вас ничего не получится!» Вон из моего проекта!

Кроме того — мы применяем аджайл. Мелкие итерации. И наши риски, и риски клиентов — ничтожно малы! А еще у нас есть типовые и четко очерченные в договорных отношениях этапы (не путать с agile-итерациями ;). Каждый раз, когда мы сталкиваемся с неопределенностью — мы разбиваем задачу на несколько мелких этапов и наши риски снижаются. Это же просто! Да? А теперь плохая новость:

Снижая риски добавлением этапов, мы снижаем рентабельность* всего проекта.

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

Итак, у нас есть абсолютно типовые этапы:

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

Мы только что завершили проведение конференции DotNetConf – нашей онлайн конференции сообщества разработчиков, которые любит платформу .NET и открытые проекты.

Все доклады конференции уже доступны по ссылке на официальном сайте.

Платформа конференции

Довольно забавно называть “платформой” наше ПО, на котором работала конференция, это звучит слишком “энтерпрайзно” и официально. В прошлом мы провели конференции aspConf и mvcConf с помощью спонсоров, которые оплачивали необходимые расходы. Мы использовали мощности Channel 9, студию и вещали видео из Сиэтла или через Live Meeting.

Однако, в этом году нам захотелось провести конференцию как можно проще, дешевле и более распределенно. Мы хотели пригласить спикеров из любой временной зоны. Насколько это было дешево? Примерно в $10. Точный счет будет подсчитан позднее, нам просто хотелось поднять мощности, провести мероприятие и затем отказаться от полученных ресурсов.

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

Проведя анализ существующих механизмов аутентификации пользователей я выделил 3 основных характеристики, которыми обладает каждый из них:

Доброго времени суток.

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

Вначале наш отдел делал отчеты,
— Принимая задачи по outlook
— Составляя sql-запрос
— Отправляя результаты заказчику в xls
— В лучшем случае, сохраняя sql-код куда-то в папку (а иногда и не сохраняя)

Но это было скучно и неинтересно. Так появилось простейшее приложение на PHP,
в котором каждый отчет был представлен в виде php-файла с одним классом, имеющим единственный (помимо конструктора) метод show()

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

Сервер отчетов был переписан на django, где была «админка» и код приложения уже не правился.
В процессе работы снова накопилось несколько мыслей,
в итоге сервер был снова переписан.

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

Это рабочий инструмент, который вы можете (если захотите) использовать в работе,
который нам использовать просто нравится.

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

Работа с API различных порталов — одна из самых распространенных задач, возникающих при разработке под Android. Казалось бы, ничего сложного — асинхронно посылать HTTP-запросы и отображать ответы, но дьявол, как всегда, кроется в деталях.

Основные антипаттерны:

• Отправка запроса прямо из кода Activity в основном треде — тут без комментариев, т.к. это приводит к заморозке UI, вследствие чего система может предложить убить приложением;
• Отправка запроса из кода Activity при помощи AsyncTask — плохо, т.к. если пользователь, к примеру, повернет экран, Activity пересоздастся и запрос придется выполнять заново, что приводит увеличению времени ожидания и количества потребляемого трафика;
• Отсутствие кэширования — после каждого действия пользователя ему придется ждать полной загрузки данных.

Доброго времени суток, уважаемые хабровчане! Недавно я заинтересовался Python и, в частности, веб-фреймворком Django. После ознакомления с основными возможностями захотелось найти бесплатный хостинг с поддержкой Django. Каюсь, в тот момент напрочь забыл про GAE, но, почитав вчера про оный, понял, что выбор получился ничуть не хуже. Итак, встречайте, AppFog! (осторожно, под катом картинки!)

Давно на хабре не было постов про CSS и я решил восполнить этот пробел. Сегодня мы учимся готовить зубчатый фон используя только средства CSS и никаких изображений!

Важные требования к такому забору:

• Никаких изображений!
• Он должен спокойно тянуться по горизонтали
• Обязательно должен поддерживать неравномерный фон у подложки
• Фон не должен требовать никакой экстра-разметки. Лучше всего будет избегать псевдо-элементов (экономия — хорошо).

Поддерживаемые браузеры: Chrome, Firefox (> 3.6), Opera (>= 12), Safari (>= 5), IE10.

Для IE 7, 8 у нас будет фоллбэк в виде обычной заливки. А вот с IE9 проблема — он не поддерживает градиенты, но при этом понимает hsla и rgba цвета. Воистину «великолепный» браузер. Что ж, его пока придётся игнорировать. Если кто–то подскажет хороший фоллбэк для IE буду только благодарен.

Здравствуйте, уважаемые.


В данной статье хочу познакомить вас с новым продуктом “FBA Toolkit”, который существенно облегчает процесс разработки корпоративного мобильного приложения на 1С + Android.
“FBA Toolkit” это:
— разработка «нативного» приложения Android в родной IDE на языке Java;
— 1С: Предприятие 8.1 (8.2) в роли источника данных, корпоративной информационной системы.

В первую очередь, фреймворк будет полезен программистам 1С, которые хотели бы заняться разработкой бизнес-приложений под Android, но испытывают трудности с освоением новой для них платформы. Чтобы начать разработку достаточно будет начальных знаний Java. Далее я покажу, как создать рабочий прототип клиент-серверного приложения буквально за пару часов.

Около года назад, после первого знакомства с Flurry у меня прямо вырвалось — она же рвет Google Analytics как Тузик грелку тряпку какую-то материю. И обещался написать об этом повесть. Еще до знакомства с Flurry, для своего первого приложения пришлось использовать именно гугловую аналитику, стабильную но в бета-версии. С того момента все повзрослели но я так и остался с Flurry. Пост о том, какой от нее прок и как ее готовить. А готовить ее как два пальца яйца о сковородку.

Здравствуйте, уважаемое Хабрасообщество!

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

Долгое время я использовал Twitter Bootstrap, но он не мог удовлетворить все потребности. Приходилось верстать дополнительные кнопочки и писать скрипты. Но вот однажды, я познакомился с замечательным UI-фреймворком KendoUI от Telerik. Что из этого получилось под катом.

Год назад мы с командой решили перейти с SVN на Git. Зачем это было надо — писать не буду, т.к. на эту тему уже и так много написано. А хочу я описать типичные алгоритмы работы, понятные человеку, который долгое время пользовался SVN. Ниже — памятка, написанная для команды год назад, чтобы легче было мигрировать. Надеюсь, кому-нибудь пригодится.

Знакома ли вам ситуация, когда запуск проекта переносится только из-за того, что не готова документация к API или чему-то подобному? Может быть, вам приходилось тратить месяц на разработку системы ведения документации с пользователями, правами доступа и мощным редактором? Вы сами работаете над документацией и погрязли в этой рутине? Вы ответили «Да» на все вопросы?