Профессиональный 3D-сканер, с помощью которого можно оцифровать реальный объект, получив его компьютерную модель, стоит десятки тысяч долларов. Мы же сможем провернуть то же самое с помощью специальной программы, лазерной указки и веб-камеры. Всего долларов за тридцать.

Константно-переменный дуализм.

Настройки у программ существуют давно, от самых древних ассемблерных программ, имеющих в своём коде константы в качестве настроек. Обновление таких программ происходило с полной заменой кода, поэтому изменение системы настроек не влекло отрицательных последствий. В худшем случае, приходилось переучиваться пользованию интерфейсом. Положение стало меняться при преемственности типов данных и настроек программ. В своё время Microsoft уделяла огромное внимание совместимости программ и данных в операционных системах, в чём была их сильная сторона. Да и сейчас поддержка режима XP Mode — это продолжение политики совместимости. Применительно к веб, пользователям часто встречаются ситуации, когда данные и настройки у них остаются от прежних версий (в куках, в сторонних базах данных), а версия программы — на сервере или скрипт на клиенте — изменяется. Возникает проблема совместимости версий программ и данных и необходимость выработки некоторой политики поддержки совместимости. Новая версия может не устроить по совместимости с браузерами (из-за багов или неполной поддержки), тогда откат к прежней на время исправления багов не должен сопровождаться потерей или искажением настроек, при том, что количество их может меняться с изменением версии.

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

Вторая, заключительная часть статьи про опыт внедрения подхода Getting Real от компании 37signals на примере нашей компании. Начало опубликовано вчера.

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

А вот один из секретов про качество поиска начну раскрывать прямо здесь и сейчас. Это новая штука под названием expression ranker, добавленная в версии 2.0.2-beta, (правильный русский перевод еще не придумали), и чуть подробнее я сейчас расскажу про него под катом. Вкратце, оно позволяет задавать свою формулу ранжирования прямо на лету, и даже отдельную для каждого запроса. В общем, эдакий конструктор, который дает возможность каждому попробовать построить свой личный MatrixNet, с четырехмерными шахматами и оперными певицами.

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

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

Примечание: автор текста — Всеволод Леонов, Академия проектов Farminers

Всем привет. Если вы уже сделали упражнение от Александра Бородича и написали elevator pitch, самое время начать работу над более детальным документом (просто pitch, или pitch book), который вы отправите потенциальному инвестору после того, как он купился на ваш elevator pitch.

Я попытаюсь просто объяснить, как работают замыкания в Javascript, как работает this, как создавать конструкторы для своих классов и чем различаются различные подходы к их созданию.
Статья не претендует на новаторство, но достаточно доступные объяснения how it works для новичков я не видел, и на мой взгляд — это три самых узких места в Javascript (не привязанному к какому либо контексту, серверу или браузеру, например).

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

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

Добрый день, хабровчане.

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

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

Morpheus: Знать путь, и пройти его — не одно и то же.
Loyn: Знаю, дружище. Об этом я и хочу поговорить сегодня.

В связи с тем, что на Хабрахабре не нашёл я описания данного простого и в то же время удобного способа создания простых «тултипов» — всплывающих подсказок, я решил о нём написать.
В данном методе не будет использоваться JS, мы довольствуемся лишь CSS3 и HTML5.

Введение

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

Интересно, что, как правило, даже тяжелые фреймворки (вроде Symfony или RoR) на «медленных» языках, в production-окружении работают достаточно сносно по скорости, а основные «тормоза» вызываются SQL-запросами и неграмотным кешированием (к примеру, инициализация достаточно сложной и большой конфигурации проекта на Symfony занимает около 80 мс, а времена исполнения страницы, при этом, иногда достигают секунды и более).

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

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

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

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

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

Yaf — это PHP микро-фреймворк, взявший за основу структуру приложения Zend Framework, но написанный на С и является PHP extension доступным через PECL.

Основной (и единственной) задачей для написания его послужила необходимость максимально быстрой (сравнимой с php) обработки запросов в парадигме MVC но с удобством предоставляемым Zend Framework.

Yaf и Zend Framework, имеют аналогичные API и подобную концепцию, сохраняя при этом совместимость.
Я сгенерировал тестовое приложение (zf create project test) и провел небольшой синтетический тест производительности.

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

При попытке отредактировать этот старый пост слетело всё форматирование. Может быть я его когда-нибудь исправлю.

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

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

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

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

В этой статье я хочу рассказать о настройке и использовании домашней системы слежения. Вы сможете сделать за любой территорией, попадающей в поле зрения вышей веб-камеры, отправлять себе сообщение при обнаружении активности в этой области, делать снимки, транслировать изображение по сети (можно прикрутить авторизацию для доступа видео с вашей веб-камеры и смотреть удаленно, если у вас есть статический ip) вообще что захотите — полный контроль и свобода выбора, что в общем характерно для ос gnu/linux и подобных (в дальнейшем речь пойдет именно о linux).

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