Намба 0: Вступление

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

Как раз в этот момент я хотел подучить программирование и искал несложную задачу. Сайт я накидал довольно быстро — за пару вечеров, рассказал о нем коллегам по работе и паре знакомых в IRC, и собирался уже о нем забыть, как вдруг обнаружил, что за два дня сайт посетило 500 человек, из которых чуть ли не треть подписалась на RSS. Стало понятно, что концепция людям понравилась. Немного прилизав сайт внешне, я решился показать его Хабрасообществу — Шортики — короткие и смешные, прошу любить и жаловать.

P.S. Учитывая то, что это не совсем стартап (проект пока некоммерческий, да и «стартап» — слишком громкое слово для моей поделки), приобретенная за годы пребывания на сайте хабрасовесть не позволила мне написать нетехническую статью. Поэтому, под катом вас ждет занимательная история о том, как мы готовили Шортики к Хабраэффекту.

Автор: Кристина Бьоран
Источник: www.uxbooth.com/blog/psychological-manipulation-in-ecommerce-design

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

В июле 2011 года в одном из выпусков интернет-издания Wired, профессор психологии и специалист в области поведенческой экономики, Дэн Ариели, опубликовал статью на тему психологических приемов, используемых сегодня несколькими крупнейшими веб-сайтами. В этой статье, которая называлась «Gamed» («Пойманные»), автор продемонстрировал, как такие сайты, как Amazon и Groupon, при помощи элементов дизайна стимулируют определенные сценарии поведения, направленные на осуществление покупки.

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

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

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

— Почему нет сообщества Пролога?
— Оно есть. Такова специфика языка, что он очень полюбился в академической среде (большинство Prolog систем пишутся в различных университетах и наоборот практически любой университет пишет свой Пролог), из-за этого можно сказать страдает и применимость языка. Стоит отметить, что сообщество небольшое, но очень лояльное: практически все известные языки нашли свое отражение в современных языках (Lisp, ML -> F#, Scala; Smalltalk -> Java, Scala (агенты), скриптовые -> Ruby), в отличие от Пролог.

Думаю на этом хватит философских рассуждений и можно приступить к реальным примерам :)

В конце как обычно ожидает задача на приз.

Начну не с самих методов раскрутки, а с подготовки, что является не менее важным, чем сама раскрутка и продвижение приложения. Сразу оговорюсь, что привожу в пример только платные приложения и российский Apple Store.

Здравствуйте, хабражители!

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

Итак, к делу.

Введение

Когда у меня была карточка от Nvidia, вопросов с воспроизведением видео на ней не было: Скачиваешь последний snapshot с сайта mplayer, устанавливаешь проприетарные драйвера, собираешь с поддержкой vdpau, добавляешь соответствующие кодеки и устройство вывода, и всё работает (стоит заметить, что в некоторых дистрибутивах поддержка vdpau уже есть в mplayer).
Не давно у меня появился AMD Radeon, при выборе видеокарты мысленные преграды существовали для использования Radeon'a, в том числе касающиеся настройки аппаратного декодирования. Но они были успешно сломлены финансовой стороной вопроса, так и появился у меня AMD Radeon HD с UVD3.
Данная статья появилась как результат поиска на тему: как заставить видеокарту декодировать видео + сохранить в качестве заметки на будущее. Итак приступим.
Примечание: В комментариях было указано, что это устаревший способ, новый способ описан по ссылке, а готовый скрипт лежит тут.

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

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

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

Так появилась программа Quick Config.

Предисловие.

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

Ошибки в обработке ошибок являются наиболее распространенным источником ошибок

Бредня, пришедшая в голову при написании этой статьи

Основные баталии по поводу того, что лучше использовать при программировании на C# – исключения или коды возврата для обработки, ушли в далекое прошлое (*), но до сих пор не утихают баталии другого рода: да, хорошо, мы остановились на обработке исключений, но как же нам их обрабатывать «правильно»?

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

Существует множество «за» и «против» такого способа перехвата и обработки исключений, но сегодня я хочу рассмотреть несколько другую тему. А именно тему обеспечения согласованного состояния приложения в свете возникновения исключения – три уровня безопасности исключений.

 

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

Итак, грехи:

1. Медлительность
2. Блокирующее взаимодействие
3. Неуместные ограничения
4. Ненастроенность
5. Несамостоятельность
6. Забывчивость
7. Гордыня

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

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

Естественно, статью можно перевести и в технику взлома ресурсов. Но чтобы знать, как защищать — надо знать, как взламывать. Ответственность за приобретенные знания вы берете на себя ;)

И если вы, как разработчик, будете знать хотя бы некоторые принципы и техники, что используют хакеры — думаю вам станет чуть спокойнее за них (ресурсы) и результат вашей деятельности приобретет более высокий уровень

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