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

• Что есть информация?
• Как мозг представляет знания?
• Что такое язык?
• Какова роль языка в мышлении?
• Как совершаются поступки?
• Как осуществляется планирование?
• Какова природа фантазий и воспоминаний?
• Что такое мотивация?
• Какова природа эмоций?
• Откуда берется многообразие эмоциональных оценок?
• Что есть смысл?
• Как рождается мысль и какова ее природа?
• Что такое внимание?
• Что есть любовь?
• Что есть гармония и красота?

Несколько дней назад меня очередной раз посетила Мысль. Мысль была не нова и довольна навязчива: «давай перейдем на Windows8. Ну пожааалуйста». И так как отогнать её никак не получалось, я запаслась чаем и печеньками и приступила.

На установку системы и всех необходимых программ ушло не более двух часов, но затем наступил самый интересный момент: мне нужно было развернуть рабочее окружение, а именно — GIT + локальный сервер (Apache, MySQL, PHP, nginx, memcached, mongodb). Помятуя об опыте предыдущих установок, на этот раз я решила весь процесс задокументировать и сохранить для потомков.

• [Kinect for Windows SDK. Часть 1. Сенсор]
• Kinect for Windows SDK. Часть 2. Потоки данных
• Kinect for Windows SDK. Часть 3. Функциональные возможности
• Играем в кубики с Kinect
• Программа, апорт!

Три части обзорной статьи можно считать вводными к двум другим: «Играем в кубики с Kinect» и «Программа, апорт!». Хотя хронологически они идут последними. Более того, за время их написания Microsoft успел выпустить новую версию SDK – 1.5. Какой удар со стороны корпорации!

Как вам должно быть известно, Kinect – это бесконтактный контроллер, т.е. скажем в играх, вместо того, чтобы яростно стучать по клавиатуре или терзать gamepad, вы размахиваете руками и ногами и время от времени голосом даете какие-то команды. Самое время спрятать дорогие китайские вазы X века подальше!

Это перевод оригинальной статьи Designing for touch



Принципы управления привычными интерфейсами настольных систем оказываются перевернуты с ног на голову, когда дело касается интерфейсов сенсорных. В данной статье приводятся рекомендации специалиста по проектированию взаимодействий Джоша Кларка (Josh Clark) относительно разработки интерфейсов для сенсорных мобильных устройств и сравниваются сенсорные интерфейсы устройств Android, iPhone и iPad.

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

Сегодня мы поговорим об отечественных стандартах на проектную документацию. Как эти стандарты работают на практике, чем они плохи и чем хороши. При разработке документации для государственных и серьезных частных заказчиков у нас обычно нет выбора — в требования по документированию ТЗ вписано соблюдение стандартов. На практике мне приходилось сталкиваться с различными примерами недопонимания структуры стандартов, того, что должно быть в документах и зачем эти документы нужны. В итоге из-под пера техписателей, аналитиков и специалистов выходят порой такие перлы, что непонятно, в каком состоянии сознания они писались. А ведь на самом деле все достаточно просто. Поиск по Хабру не вернул ссылок на более-менее целостный материал на данную тему, потому предлагаю закрасить этот досадный пробел.

Если в одном из моих прошлых постов речь шла о довольно современном подходе к построению сбалансированных деревьев поиска, то этот пост посвящен реализации АВЛ-деревьев — наверное, самого первого вида сбалансированных двоичных деревьев поиска, придуманных еще в 1962 году нашими (тогда советскими) учеными Адельсон-Вельским и Ландисом. В сети можно найти много реализаций АВЛ-деревьев (например, тут), но все, что лично я видел, не внушает особенного оптимизма, особенно, если пытаешься разобраться во всем с нуля. Везде утверждается, что АВЛ-деревья проще красно-черных деревьев, но глядя на прилагаемый к этому код, начинаешь сомневаться в данном утверждении. Собственно, желание объяснить на пальцах, как устроены АВЛ-деревья, и послужило мотивацией к написанию данного поста. Изложение иллюстрируется кодом на С++.

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

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

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

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

Зачем что-либо измерять?

Есть проект. Ваш любимый, родной, которому вы желаете расти и процветать.
Но как вы оцените его процветание, если нет критериев этого самого процветания?
Как вы сможете оперативно среагировать на проблемы до того, как они стали неисправимыми, если не будете использовать «датчик грядущей Ж»?
Как вы поймёте, что именно следует улучшать, если вам неизвестен источник проблем?

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

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

А если не приходят, значит метрику можно смело выбросить ;)

Одна из сложностей, с которой, по моему опыту, сталкиваются практически все разработчики и дизайнеры, работая над приложениями для Windows 8 и Windows Phone, начинается прямо с порога – с проектирования того, как пользователь будет взаимодействовать с приложением (UX и UI).



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

В продолжение темы про дерево немного переделал код и подключил jQuery. Теперь дерево живое, узлы разворачиваются, как этого многие ожидают видя подобное дерево.
Теперь оформление дерева делает скрипт — сам расставляет маркеры для элементов с вложенными узлами.
Благодаря использованию скрипта HTML стал проще.

UPD 05.04.2009: обновлены скрипты, есть несколько вариантов скриптов.
UPD 09.04.2009: продолжение

Эта статья является продолжением статьи про ГОСТ 28147-89. Как уже говорилось ранее, ГОСТ 28147-89 поддерживает четыре режима работы, но, пожалуй, главным из них является режим простой замены, который используется как самостоятельно, так и как составная часть других режимов.

В статье приведен код на c++, реализующий данный режим.

Файлы здесь.

Автор: Эндже Альбертини (Ange Albertini)
Перевод на русский: Lyr1k

---

ТГ-канал: @alizar_news. Мои лучшие статьи и переводы с Хабра за 20 лет

На написание данной статьи меня подтолкнул топик HTML в PDF, правда по причине того, что он посвящен языку php, лично мне он был мало полезен, т.к. весь опыт работы с php у меня сводился в переводе нескольких скриптов на C#, поэтому я решил сделать небольшой обзор того, что доступно для работы с pdf по средствам языка C#.

Ко мне в список попало 7 библиотек, о которых я скажу несколько слов, а для самой популярной (судя по ответам на stackoverflow), я напишу, как с помощью неё сделать простейший документ. Сразу скажу, что это iTextSharp и работа с ней будет описана в конце статьи.

Первая часть статьи «Разработка технического задания «Что это такое, зачем оно нужно, с чего начать и как должно выглядеть?» вызвала немалый интерес. Кроме своей рассылки, я ее опубликовал и на известном сайте разработчиков Инфостарт, где она вызвала еще больший интерес, что не может не радовать. Как и обещал, пишу продолжение.